ubuntu-phone team mailing list archive

[Simon Busch <simon.busch@xxxxxxxxxxxxx>]

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.

> It also appears that Bluez5 includes a plugin called autopair.  From a
> description in the plugin itself:
>
> Plugin to handle automatic pairing of devices with reduced user
> interaction, including implementing the recommendation of the HID spec
> for keyboard devices.

That works in a lot cases and is a good thing to have. However it tries 
to handle th common cases for keyboards but if one comes with a random 
pin set the autopair plugin can't do anything and will fail to pair both 
devices. Also from what I understand from Sebastian's idea is that the 
service then also triggers the UI to get the different popups needed for 
pairing and other things, right?

regards,
Simon