ubuntu-phone team mailing list archive

[Tony Espy <espy@xxxxxxxxxxxxx>]

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 ).

Regards,
/tony