| 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 ).
There is actually no re-pairing. Pairing happens only once and when device is paired it is directly connected without doing any pairing. With Secure Simple Pairing there are multiple ways how to archive a bond (that is what the result of pairing is). With Just-Works it is even possible to pair with a PIN or passkey. However as Tony says we should maybe reevaluate the different use cases and make sure our implementation matches them. For example bluetooth devices with bluetooth > 2.1 supports SSP which uses passkeys rather than PINs which are digits only and can be longer than 6 ...
regards, Simon
| Thread Previous • Date Previous • Date Next • Thread Next |
