Skip to content
This repository has been archived by the owner on Jun 27, 2019. It is now read-only.

Add the Bluetooth agent API (for BlueZ) v3 #2107

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

vcgomes
Copy link
Contributor

@vcgomes vcgomes commented May 27, 2016

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 v2 (#2074):

  • Fixed comments from review;

Changes from v1:

  • BlueZ D-Bus API has changed (but still marked as experimental, so no API compatibility is promised), this version uses the current upstream API;
  • More helpful information when browsing for devices, i.e. the device name is printed;
  • With the new D-Bus API, it is now possible to obtain the connection in which a GATT operation is happening.

vcgomes added 13 commits June 2, 2016 18:02
In case there's no known handler for a given (interface, path) pair,
it's should not be considered an error.

Signed-off-by: Vinicius Costa Gomes <[email protected]>
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]>
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]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant