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) #2053

Closed
wants to merge 4 commits into from

Conversation

vcgomes
Copy link
Contributor

@vcgomes vcgomes commented May 17, 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.

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]>

SOL_API int
sol_bt_conn_pair(struct sol_bt_conn *conn,
void (*cb)(void *user_data, bool success, struct sol_bt_conn *conn),
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can have an integer success/status variable to indicate a broader range of errors

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I could gather from the Zephyr API, there's no way to give more information than that.

@vcgomes
Copy link
Contributor Author

vcgomes commented May 20, 2016

The new (and improved) version is at #2074, closing.

@vcgomes vcgomes closed this May 20, 2016
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.

2 participants