Services connected in BlueZ 5

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

Hi Christopher,

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:

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

Hi Jakub,

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... :/

Hi Christopher,

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.

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.

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

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