Recently I upgraded my PC to bazzite 43 and my headphones Baseus H1 Pro autodisconnect themselves for no apparent reason. I’m using baseus bt dongle to connect my pc to headphones. Bluetoothctl gives me this output
[CHG] Device 41:AA:00:A1:EF:88 Connected: yes [NEW] Endpoint /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep1 [NEW] Endpoint /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep2 [NEW] Endpoint /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep4 [NEW] Transport /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep2/fd1 [CHG] Transport /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep2/fd1 Delay: 0x0898 (2200) [CHG] Transport /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep2/fd1 Volume: 0x0045 (69) [CHG] Device 41:AA:00:A1:EF:88 ServicesResolved: yes [DEL] Transport /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep2/fd1 [DEL] Endpoint /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep1 [DEL] Endpoint /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep2 [DEL] Endpoint /org/bluez/hci0/dev_41_AA_00_A1_EF_88/sep4 [CHG] Device 41:AA:00:A1:EF:88 ServicesResolved: no [SIGNAL] BREDR.Disconnected - org.bluez.Reason.Remote, Connection terminated by remote user [SIGNAL] Disconnected - org.bluez.Reason.Remote, Connection terminated by remote user [CHG] Device 41:AA:00:A1:EF:88 Connected: no
The problem seems to go away after restarting all services with sudo systemctl stop bluetooth sudo rm -rf /var/lib/bluetooth/* sudo systemctl start bluetooth systemctl --user restart pipewire wireplumber\
If anyone knows what seems to be a problem I’ll be glad for an explanation how to fix it
@rzeczyspisane when you mentioned you were using a dongle that brought back memories (nightmares actually) of the years I spent using a wired USB headset to attend meetings in WebEx, etc.
There was a common hw bug commonly known as the “longer than 1 hour meeting USB issue”. A lot of us came to the conclusion that some USB controller / bridge chip was overheating when in constant use for more than an hour.
The workaround was to unplug from the USB port, wait 10 secs or so (presumably to allow the chip to cool a little and the firmware to detect the new cooled state) and then plug it back in.
I hope that is not the case for your sake, but you might try to unplug your USB dongle, wait some # secs and plug it back in. If you are not able to reconnect then what I am describing might not be related to the problem.
If that does work, then I am afraid the long term solution will be to eliminate the use of the dongle - for example, by using a dedicated bluetooth expansion card on the PCI bus instead.
Hopefully others will have a better answer for you. But I thought I would share my experience from the past …
I think I have had every bug possible on Linux and Windows with Bluetooth headphones, I now have a collection of Bluetooth usb dongles, feels like I’m collecting stamps or something, but I have them ranging from 4.2 all the way up to 5. something, probably 5.3, when ever I start to have issues, I swap them out for another, guaranteed one of the will work :).
I find the most reliable non USB ones to be from Intel, like the AX2XX or newer m.2 cards, and they are the only ones I never have issues with, but I have one particular USB dongle with a large removable aerial, I think its a version 5.2, this one is also quite solid under Linux, and functions great with Bazzite 43, I use a set of Ears 2, Sony XM5’s along with several Xbox controllers with it, was a rando purchase of Amazon, I will fire that machine up later today and grab the hardware details and post here in case your looking for something that works flawlessness.
That would be great. But my problem is that I have an ASUS motherboard and BT on it wasn’t so great, so I switched to baseus dongle (0bda:a729 Realtek Semiconductor Corp. Bluetooth 5.3 Radio under the hood) that was working fine during bazzite 42, but upgrading to bazzite 43 made that it has problems with one of my headsets.
So the problem is probably regression in bluez and not the fault of the dongle, but rather headset-linux specific bug.
In the bug report people say that it is headset specific, so I doubt that I should be looking for the issue in the dongle.
If you wish to send me the hardware tho I will be more than happy
@rzeczyspisane - I have shared @NexGen3D ‘s experience with USB dongles. I am fortunate to have a laptop this time that seems well supported. But I still need to use the workarounds I mention above.
One other thought I had was to use a powered USB hub. That would not be an ideal long-term solution, but would at least give you another data point.
One of the things that changed for 43 (all Universal Blue) is that the kernel version is now unpinned; in favor of moving away from btrfs as the default file system.
It is theoretically conceivable that your dongle might benefit from more available power given a different kernel, et al.
like I’ve already linked. The problem is with bluez or with kde. If the update doesn’t touch one of these components the issue will persist
Now i just use sudo systemctl restart bluetooth.service
works once per session. It’s annoying, but the problem is known, so you can either pin bazzite to latest 42 release or just use this fix until upstream will fix it.
@MajesticToday (cc: @rzeczyspisane ) like I said above bluetooth has been problematic for years. I am re-watching the video right now where Greg Kroah-Hartman (stable linux kernel maintainer) suggests that bluetooth drivers are one of the most volatile part of the kernel because the hardware is so brittle (he actually said it is so bad). And there is bluez, pipewire, etc. other layers that have a surface area for bugs.
It works for awhile and then it breaks in some small - but, important way.
Please adjust your expectations to rely on workarounds with which you find success. What works for me is to manually disconnect before the machine needs to sleep or I need to reboot.
For me simply restarting the bluetooth.service is not a 100% solution. Some times the hardware just needs a line-level reset - which requires a reboot without any device connected to it.
I had similar issues after upgrading, and they were fixed by clearing the bluetooth cache at /var/lib/bluetooth (which you’ve already tried, but this will erase your bluetooth pairing history) and clearing the wireplumber cache at ~/.local/state/wireplumber (I didn’t see any side effects of this but I don’t really have custom settings for my audio devices). Clearing the bluetooth cache was something I did when updating to Fedora 41 broke this same connection before for me, and this time it made it work sometimes, but it was clearing the wireplumber cache that actually fully fixed it this time around.
To be clear, I mean deleting the contents of these folders, not the folders themselves, but there might not be a significant difference between the two.