Services connected in BlueZ 5

Services connected in BlueZ 5

[Christopher Schramm]

Hi guys,

I'm maintaining blueman, a DE-independent bluetooth manager. It was
orphaned for some time, keeping it with deprecated APIs, e.g. BlueZ and
NetworkManager. Together with a handful of awesome contributors we
revived the development and are bringing blueman back to most distributions.

We finally need to finish the migration to BlueZ 5 and I'm a little
stuck with the services. The original blueman code heavily relied on the
dbus Interfaces provided by BlueZ 4 for serial, network, input, and
audio services. Those parts are ported to abstract service classes now
which detect services based on UUIDs (here's the commit [1] for those
curious; note we're currently supporting both BlueZ 4 and 5 for one
major version (2.0) of blueman).

I know there are basically two ways to connect to services in BlueZ 5:
Device.Connect and Device.ConnectProfile.

I really like the idea of listing all services available and supported
and let the user connect to specific ones. The problem with this is I
did not find a way to detect if a given service is connected or not. So
I switched back to the generic Device.Connect method [2]. I think this
method and the Device.Connected property are pretty awkward, since not
all services are handled. E.g. from my experience a NAP service does not
get connected by Device.Connect, but if you connect the specific NAP
service Device.Connected gets set. Neither we as developers, nor the
users seem to have an indicator for which services are actually
connected and which are not.

I also experienced issues with Device.Connect for my test devices: If I
call it on one of my Android devices which provides some audio service I
get "No such file or directory". If I call it on a Logitech mouse I get
"Input/output error". I can only connect to them right after pairing
sometimes. These problems did not show up in BlueZ 4 and I think it was
much better when testing with Device.ConnectProfile.

So, is there any way to determine a specific service's connection state
in BlueZ 5? If not, ConnectProfile / DisconnectProfile seem pretty
useless, since one is left in the dark, so the only valid way would be
using Connect and hope all services desired by the user get connected
which is pretty unsatisfying. Can you confirm the awkward behavior of
Device.Connect and Device.Connected e.g. in conjunction with a network
service?

I appreciate any help and feedback. If you're curious, please take a
look at our BlueZ 5 ticket [3] and feel free to contribute.

Regards
Christopher Schramm

[1]
https://github.com/blueman-project/blueman/commit/ad8aaf5253546b697115d64ab06a1575ec9ac1e6
[2]
https://github.com/blueman-project/blueman/commit/e03f1ab3eac396df813a0161529a6c3823d5ccb4
[3]
https://github.com/blueman-project/blueman/issues/13#issuecomment-59015346

Re: Services connected in BlueZ 5

[Jakub Sitnicki]

Hi Christopher,

On Sun, Jan 04, 2015 at 04:06 PM CET, Christopher Schramm wrote:
> So, is there any way to determine a specific service's connection state
> in BlueZ 5? If not, ConnectProfile / DisconnectProfile seem pretty
> useless, since one is left in the dark, so the only valid way would be
> using Connect and hope all services desired by the user get connected
> which is pretty unsatisfying. Can you confirm the awkward behavior of
> Device.Connect and Device.Connected e.g. in conjunction with a network
> service?

While I can't definitely confirm that it is not possible to check if
specific service is connected because I'm not a developer in this
project, I would say that this note from Device1.DisconnectProfile() API
docs suggests it:

> There is *no connection tracking* for a profile, so as long as the
> profile is registered this [DisconnectProfile()] will always succeed.

Also, in case you haven't already seen it, I think you might find
interesting a part of the discussion of this patchset from some time ago
(regarding the need to show in UI which services are connected):

http://thread.gmane.org/gmane.linux.bluez.kernel/36507

Hope this helps,
Jakub

Re: Services connected in BlueZ 5

[Christopher Schramm]

Hi Jakub,

> Also, in case you haven't already seen it, I think you might find
> interesting a part of the discussion of this patchset from some time ago
> (regarding the need to show in UI which services are connected):
> 
> http://thread.gmane.org/gmane.linux.bluez.kernel/36507

thanks for pointing me at this. Unfortunately to me Marcel confirms that
ConnectProfile / DisconnectProfile isn't of any use for management UIs
and even says that this is by design. That leaves me with
Device1.Connect as the only option to connect services and no way to
check which services have actually been connected.

It also seems to mean that connecting a device with a network service
and something else, e.g. and audio service, (say a common Android device
with tethering) results in total confusion for the user. If I'm not
totaling seeing or doing things wrong, we e.g. have the following case:

* Provide user with ways to connect to a) the NAP (Network1) and b) the
"other" services (Device1).

* User requests to connect to NAP -> Call Network1.Connect.

* Device1 changes Connected property to 1 -> Do not provide the way to
connect to the "other" services anymore, since at least some are connected.

This leaves the user with no way to connect to the other services if the
NAP is already connected. Pretty unsatisfactory situation... :/

Re: Services connected in BlueZ 5

[Luiz Augusto von Dentz]

Hi Christopher,

On Sun, Jan 18, 2015 at 7:02 PM, Christopher Schramm
<blueman@cschramm.eu> wrote:
> Hi Jakub,
>
>> Also, in case you haven't already seen it, I think you might find
>> interesting a part of the discussion of this patchset from some time ago
>> (regarding the need to show in UI which services are connected):
>>
>> http://thread.gmane.org/gmane.linux.bluez.kernel/36507
>
> thanks for pointing me at this. Unfortunately to me Marcel confirms that
> ConnectProfile / DisconnectProfile isn't of any use for management UIs
> and even says that this is by design. That leaves me with
> Device1.Connect as the only option to connect services and no way to
> check which services have actually been connected.

You don't know what service have been registered and match with remote
device services to use them properly anyway, I do however agree that
ConnectProfile/DisconnectProfile are useless as they are right now and
having objects for each service would be better, however I wouldn't
expose them in any UI but use them for testing/debug and external
connection policies if non-standard profiles are used.

> It also seems to mean that connecting a device with a network service
> and something else, e.g. and audio service, (say a common Android device
> with tethering) results in total confusion for the user. If I'm not
> totaling seeing or doing things wrong, we e.g. have the following case:

Network and Audio are normally integrated directly into their
subsystems, if you want to connect a network use NetworkManager or
connman both will give all the information needed, this model is
actually quite similar to other buses such as USB, the only different
is that for Bluetooth you need an UI to pair and connect, but don't
except the user to know what is A2DP, HFP, etc, they have no clue.

> * Provide user with ways to connect to a) the NAP (Network1) and b) the
> "other" services (Device1).
>
> * User requests to connect to NAP -> Call Network1.Connect.

Network1.Connect is what NM and connman use to connect, the user can
use the Network UI instead so I don't see any problem with NAP in
specific.

> * Device1 changes Connected property to 1 -> Do not provide the way to
> connect to the "other" services anymore, since at least some are connected.

Device1.Connect can still be called, internally BlueZ will figure out
if there is any other service to connect to, you call it once and it
acts as you are plugging in a device and service will show in their
respective domain e.g. PulseAudio will show a new card has been added,
etc.

> This leaves the user with no way to connect to the other services if the
> NAP is already connected. Pretty unsatisfactory situation... :/

You can still connect, what you cannot do, reliably at least, is to
connect services individually from the Bluetooth UI since you have no
idea what services are enabled, most modern Bluetooth UIs work like
that nowadays except if you go into the advanced view which
traditionally have the Media and Voice settings to blacklist services
and the reason for that to exist is that apparently it was a
requirement for cars vendors, probably still is, otherwise I bet it
would be gone by now.


-- 
Luiz Augusto von Dentz