| Thread Previous • Date Previous • Date Next • Thread Next |
On 29.07.2015 17:52, Tony Espy wrote:
On 07/28/2015 11:28 AM, Simon Busch wrote:On 28.07.2015 17:20, Tony Espy wrote:On 07/28/2015 10:14 AM, Sebastien Bacher wrote:Hey there, Currently the only bluetooth agent available in ubuntu touch is implemented in system settings. Which means the settings application need to be open for bluetooth pairing to work.Is this the same on desktop ( ie. pairing only works when the gnome-bluetooth-settings app is running )?We received some bugs reports suggesting that the is a need for having request handled at any time because that's the most robust things to do and the less confusing for users (ideally known/trusted device would always be able to auto reconnect, but it seems that in practice sometime the trusted link is lost and the system need to prompt again, also other action are done in settings which make the pairing less reliable) https://launchpad.net/bugs/1474296 To address this issue we are thinking about moving the auth agent out from system settings to be a standalone service. We are going to start working on that but wanted to check first if anyone feeling strongly against it. The service might lead to a bit more power usage, but it would only be active if bluetooth is on and things like visibility would probably be configurable as well.Has anyone looked at the plugin architecture in Bluez? From a quick look, this appears to be a mechanism to extend the functionality of bluetoothd ( the main Bluez daemon ).Yeah you can do something like this directly in bluetoothd but I would try to avoid this if we write such a service with things like OBEX or other things in mind with respecting that we have to handle several things as long as our apps can't do things in the background.So before we get really deep here, has anyone written down the use cases/user stories that this component is supposed to handle? When I first read Seb's email, my assumption was that any pairing that required a PIN would be handled by system settings, and that the PIN associated with a particular device would be saved in a similar manner to how NM handles access point keys/passphrases ( vs. re-prompting for the PIN every time the device auto-pairs ). I took a quick look at: https://wiki.ubuntu.com/Bluetooth ...and it doesn't seem to cover how auto-pairing should work for devices that require a PIN. For devices that don't require a PIN, re-pairing seems to work fine without system settings being displayed ( at least it works with my BT earphones ).
The pairing case seem to be "enough" for what produce as device. As we just have devices which are marked with IO capability KeyboardDisplay (phones, tablets, PCs) we normally always end up with passkey/pin entry.
However if we take the bluetooth spec right we need to differentiate between initiator and receiver as according to the mapping table in Core 4.2 Vol 3, Part H 2.3.5.1 one side displays the PIN where the other inputs it (which can be solved with entering the same PIN on both sides too but we should try to reach a common behavior so the user doesn't get confused). BlueZ already supports all these through its agent dbus interface and we should respect those parts when they're called.
From what it looks in the ubuntu-system-settings code we nowadays don't support the DisplayPinCode call from BlueZ which is relevant for Bluetooth devices not supporting SSP (those using Bluetooth < 2.1). Will file a bug for this.
regards, Simon
| Thread Previous • Date Previous • Date Next • Thread Next |
