Bugzilla – Bug 1076898
Regression: bluetooth headset not connecting since last update, workaround included
Last modified: 2022-10-31 19:38:29 UTC
Before upgrading, connecting to bluetooth headset from TaoTronics worked correctly. I also have a cheap bluetooth watch and connecting to it with bluetoothctl worked fine.
Today I updated Tumbleweed to snapshot 20180117 and I observe the following behavior:
1) Connecting to bluetooth headset does not work any more even after a fresh boot. It connects shortly then disconnects. Both with the Plasma widget and with bluetoothctl.
2) Sometimes even after a fresh boot, the plasma widget doesn't show any of the known bluetooth devices
3) Strangely connecting to my bluetooth watch still works with bluetoothctl.
From what I remember, before the update I had bluez-5.47 and now it has been updated to 5.48.
Furthermore there is a similar report here for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1534857
The workaround, as indicated in that link, is to restart the bluetooth service with "systemctl restart bluetooth". After that the headset can connect again.
This is on a Dell XPS 13 9333 (different model than the above).
There are already logs in the Fedora ticket, I'll reboot now to try and gather some from here.
Please let me know if you need further information.
Created attachment 756957 [details]
Log with errors
I've attached the log from journalctl from the connection failure.
Please note that during the short time where the connection to the headset is done, I can hear a beep in the headset which is an indication from its hardware that the connection was done. However the laptop / bluez somehow decides to disconnect again.
Okay, so I forgot to mention something: I had the module "btusb" blacklisted by default. The reason was mostly to save some power when I don't use bluetooth. I wonder if those Fedora users did the same.
Anyway, now I removed "btusb" from blacklist and rebooted. And now it all works !
This seems to make sense because I suspect that whenever the bluetooth service is started at boot time, it needs btusb to be loaded already. So if you load the module afterwards, you need to restart the service.
At this point, if this is by design, feel free to close as the problem is solved for me.
My bluetooth adapter is built-in, so far so good.
But what happens for people who have bluetooth USB dongles ? Would btusb only load later once the dongle is plugged in ? If that's the case, then the problem I describe *might* happen for said users who might need to restart the bluetooth service.
Now this is marked as regression, it used to work with previous bluez versions. So not sure if this is something to be fixed upstream or whether this slight change of behavior / expectation is by design.
well, blacklisting the driver for the hardware is of course not helping :-)
I think bluetoothd should still pick up devices that are added after starting (hot-plugged USB dongles come to my mind).
Anyway, this is not an openSUSE problem, so I'd kindly ask you to report the issue upstream to the bluez-devel mailinglist at firstname.lastname@example.org
Thanks, makes sense.
I just observed that resuming from suspend also causes the issue and requires to restart the bluetooth service.
Thanks for mentioning the mailing list.
It was already reported by someone here on the mailing list: https://www.spinics.net/lists/linux-bluetooth/msg73824.html.
I've sent my own message there which should appear shortly in the archives.
Email discussion and investigation in progress: https://marc.info/?l=linux-bluetooth&m=151792734112865&w=2
Breaking commit in bluez: d6e9539e31c6bb5afd39ec6f09c518d232e6345d
I have added the patch from commit 1873096352f518d3247f8efb3c2e0aa8804e50ac to the bluez package in home:seife:testing
Could you please test if this fixes the issue for you? If yes, I'll submit this to Factory.
I have tested it and posted here https://marc.info/?l=linux-bluetooth&m=151815774828197&w=2
If this is the same patch from that email then yes it worked for me!
I'll test the package from your home also and report back.
Tested with bluez package from home:seife:testing and I can confirm that:
- resuming after suspend can properly reconnects the headset
- loading btusb module after restarting bluetooth service works
Thanks, package with patch is on its way to factory.
(And yes, testing the package is IMO important because a) I could have done something wrong integrating the patch and b) maybe it works against git master but not older released code :-)
Of course, makes perfect sense :-)
This is an autogenerated message for OBS integration:
This bug (1076898) was mentioned in
https://build.opensuse.org/request/show/575499 Factory / bluez
the fix has landed in Factory