This repository has been archived by the owner on Jun 27, 2019. It is now read-only.
Add the Bluetooth agent API (for BlueZ) v2 #2074
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 20, 2016
vcgomes
force-pushed
the
bluetooth-agent-v2
branch
3 times, most recently
from
8b95224
to
3babe7f
Compare
The sol-gatt API has changed, so we must keep the none implementation up to date so it at least compiles. Signed-off-by: Vinicius Costa Gomes <[email protected]>
The agent will be used when request user input, necessary mostly when pairing. The API is heavily based on the Zephyr's API, which maps nicely to the BlueZ D-Bus API. Signed-off-by: Vinicius Costa Gomes <[email protected]>
The agent will allow to user input to be handled so pairing procedures and the user can properly authorize and provide input. In Bluetooth, depending on the input/output capabilities of the device the pairing may use different procedures with different security characteristics, the choice of the input/output capabilities with the agent API depend on which of the agent callbacks are implemented. Signed-off-by: Vinicius Costa Gomes <[email protected]>
This sample tries pairing with the device (if provided) implementing only the pairing_confirm() callback, which means that the capabilties would be equivalent to a device which implements the "DisplayYesNo" capability. Signed-off-by: Vinicius Costa Gomes <[email protected]>
Signed-off-by: Vinicius Costa Gomes <[email protected]>
This allows the connection in which a GATT operation is happening to be retrieved by the pending handle. This may be useful when the value of characteristic is different depending on the device accessing it, for example. Signed-off-by: Vinicius Costa Gomes <[email protected]>
When receiving a pairing attempt, it's possible that there aren't any 'sol_bt_conn' objects associated yet, in that case, the connection object must be created. Signed-off-by: Vinicius Costa Gomes <[email protected]>
Since commit "93b64d9ca8a2bb6 doc/gatt-api: Add options dictionary to ReadValue/WriteValue" BlueZ passes a dictionary to its ReadValue()/WriteValue() operations, informing the device which is making the operation and the offset of the operation. Signed-off-by: Vinicius Costa Gomes <[email protected]>
In D-Bus, there isn't the concept of dictionaries, only dictionary entries and arrays, and using them is pretty common, so it makes sense to provide a helper to parse dictionaries. Signed-off-by: Vinicius Costa Gomes <[email protected]>
Now that sol_bus_parse_dict() is available, we can make use of it. Signed-off-by: Vinicius Costa Gomes <[email protected]>
There was a problem that some cases of GATT pending callback were being kept around for more time than was necessary. For that to work it was also needed to pay more attention to the lifetime of the buffer passed to sol_gatt_pending_reply(). Signed-off-by: Vinicius Costa Gomes <[email protected]>
vcgomes
force-pushed
the
bluetooth-agent-v2
branch
from
3babe7f
to
09b956b
Compare
| * @param data The user data to be passed to each agent callback | ||
| * @return 0 on sucess, -errno otherwise | ||
| */ | ||
| int sol_bt_register_agent(const struct sol_bt_agent *agent, void *data); |
There was a problem hiding this comment.
minor, but const void *data and also state if agent is copied or not, if not mention the memory must be kept alive during the agent lifetime (ie: no stack!)
Also, why not use the pattern "null to unregister"? we use it elsewhere. In this case to prevent mistakes, only accept a non-NULL agent if none was set. See https://github.com/solettaproject/soletta/blob/master/src/lib/io/sol-ipm.c#L235
|
overall looks ok, minor API alignments and the sample could be improved. I see lots of potential to have the agent exposed in a node type, our demo could use the form and lcd-string to do a nice pairing interface. Talk to @edersondisouza and @glima since they know these well. |
|
An updated version is at #2107. Closing this. Thanks. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds the concept of an agent, that will serve to receive input from the user during the pairing process primarily.
The API is pretty similar to what Zephyr provides, which is based on the BlueZ D-Bus API, so this should map pretty well to both. When reviewing, please see if the approach of the
sol_bt_agent_reply_*family of functions is easy to understand.Changes from last version: