blueman

blueman copied to clipboard

blueman: 2.3.5-2+b1 BlueZ: 5.66-1+deb12u1 Distribution: Debian 12 (bookwork) Desktop environment: Mate 1.26.0-2

• [x] I have consulted the Troubleshooting page and done my best effort to follow.

I have a Google Stadia bluetooth controller (gamepad). Pairing works fine via blueman.

Problem: Every now and then, the already paired device does not connect automatically, and the "connect" menu entry for the gamepad is not available.

I have not yet found a clear pattern; I feel it works after the first one or two reboots, but then the problem appears. Today the problem appeared again ("connect" menu entry missing) and this log messages appeared on the console:

blueman-applet 18.42.18 INFO     BluezAgent:56 register_agent: Register Agent
blueman-applet 18.42.18 INFO     Networking:71 set_nap   : set nap False
blueman-applet 18.42.18 INFO     AgentManager:17 on_registered: /org/bluez/obex/agent/blueman
blueman-applet 18.42.18 INFO     ShowConnected:50 enumerate_connections: Found 0 existing connections
blueman-applet 18.42.18 DEBUG    Base:60 do_g_properties_changed: /org/bluez/hci0 {'Pairable': True}
blueman-applet 18.42.18 DEBUG    DiscvManager:92 on_adapter_property_changed: prop Pairable True
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/blueman/main/DBusProxies.py", line 52, in call_finish
    proxy.call_finish(resp)
gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Unknown action ‘Activate’ (16)

Then I used bluetoothctl on the shell to list the devices and manually connect to it via connect CD:8C:5B:81:65:E7. Now blueman shows that the gamepad is connected and shows the "disconnect" context menu entry.

If blueman does not provide the connect item, it did not see any of the services (namely some audio and HID services) handled with a generic connect on the device. When that happens, please check and provide the UUIDs from the device's info window.

It happened again, and the info window shows:

Address: CD:8C:5B:81:65:E7
AddressType: public
Name: StadiaLJ5L-65e7
Alias: StadiaLJ5L-65e7
Class: 0x000000
Appearance: 0x03c4
Icon: input-gaming
Paired: yes
Trusted: no
Blocked: no
LegacyPairing: no
Connected: no
UUIDS:
  00001800-0000-1000-8000-00805f9b34fb Generischer Zugang
  00001801-0000-1000-8000-00805f9b34fb Generisches Attribut
Modalias: usb:v18D1p9400d0100
Adapter: /org/bluez/hci0

Manually connecting with bluetoothctl did not give me a gamepad, but after disconnecting and reconnecting via blueman the device was detected as controller, this time with the correct UUIDs:

00001800-0000-1000-8000-00805f9b34fb Generischer Zugang
00001801-0000-1000-8000-00805f9b34fb Generisches Attribut
0000180a-0000-1000-8000-00805f9b34fb Geräteinformationen
0000180f-0000-1000-8000-00805f9b34fb Batterie-Dienst
00001812-0000-1000-8000-00805f9b34fb Human Interface Device

:thinking: So the device at first does not indicate the HID service, which explains that blueman does not provide the connect action, and connecting from bluetoothctl does not seem to actually connect it, but re-connecting makes it work. I assume the HID service gets resolved on the first connection (you can check the info window or bluetoothctl's info command at that stage), but it's already to late at that point for BlueZ to properly connect it.

I'll look for my Stadia controller and try to reproduce this.

Do you still experience the problem? I enabled Bluetooth on my Stadia controller and played a bit but did not run into that missing services situation.

Yes, it still happens.

Any chance to reproduce it?

In the end it's some issue either with the device itself not advertising all its services or some "misunderstanding" between the device and BlueZ. To get behind it, you'd probably need either BlueZ events or even an hcidump of the sequence that leads to bluetoothd knowing of only some services. I don't see how you could get that if it's really that sporadic. In case you did not do that yet, check the bluetooth.service log for any traces of when it happened. bluetoothd might log something about it, but my hopes are low.

I would suggest two things:

1. Provide a way to connect to the controller. Currently with blueman I can only remove the controller and pair again, which is a hassle. With CLI I can at least connect it, even if I have to disconnect and reconnect later.
2. Show a warning when a connection to a device without UUIDs is established. This gives the user a hint that they need to do something, in my case dis- and reconnecting.

I see that the underlying problem is either in the controller or the bluetooth stack, and the two actions here only deal with the symptoms. But I'd rather like to have a way to deal with them now instead of hoping for a perfect bluetooth stack.

I don't see a good way to do any of that. If we provide a connect action for devices without auto-connect services, it will lead to errors in 99.999 % of cases (assuming that every 100.000th device is a misbehaving Stadia Controller of which I've actually only read about a single one yet). It's not like the device does not indicate any services. 1800 and 1801 are present.

Given that we know nothing about the source of the issue or other occurrences, do we even know that it also happens with recent BlueZ and Linux?

Then let's close this.