STEPS TO REPRODUCE
1. Pair one or more Bluetooth devices
2. Turn Bluetooth off from the applet or a global keyboard shortcut or the KCM
3. Turn it back on again
4. Open the applet's popup
A placeholder message that says,m "No Devices Found". If I restart plasmashell, the list is populated properly.
The same thing happens with the KCM; If it's open when Bluetooth is turned off and back on again, I have to leave the KCM and come back, and only then are my paired devices are visible again.
Applet and KCM device lists are populated with paired devices immediately upon turning on Bluetooth.
`bluetoothctl devices` lists them correctly when manually invoked after turning on BLuetooth again, so it seems some kind of "bluetooth turned on" signal isn't being handled properly here.
*** Bug 449109 has been marked as a duplicate of this bug. ***
The only possible thing to blame here would be the bc5a15d7fe7093a8b77a7946e113ba2cf7772f1d ([applet] Fix undefined property access) patch; although I don't see how it could've caused something like this. Does reverting it help?
Regarding the issue itself, my laptop's Bluetooth firmware is so shitty, I literally can't turn Bluetooth off and then back on and expect it to work, it seems. But the good news is, I bought an external USB adapter, so hopefully it's not so bad and maybe even reliable for things like wake-from-suspend by typing on a Magic Keyboard™.
Nah, that doesn't help.
I'm beginning to wonder if there is a regression in bluez-qt or the kernel. The reporter of duplicate Bug 449109 is experiencing it with Plasma 5.23.5, but kernel version 5.15.16, and that's the version I have as well.
> I'm beginning to wonder if there is a regression in bluez-qt or the kernel. The reporter of duplicate Bug 449109 is experiencing it with Plasma 5.23.5, but kernel version 5.15.16, and that's the version I have as well.
That's not an unlikely theory. There were some recent bug reports in bluez itself, including one that probably hits my firmware: https://github.com/bluez/bluez/issues/272
I've the same problem. Issuing "systemctl restart bluetooth.service" solves it...had not tried restarting plasma. The problem comes back every time I suspend and resume. I'm on kernel 5.16.2 and will try some earlier kernels later to confirm whether it's a kernel regression.
I am hit by this issue as well, and tried multiple kernel versions to see whether the problem was a regression or not.
I confirm that the issue is the same (all bluetooth devices disappear after suspending/resuming and `systemctl restart bluetooth` works as 'workaround') in kernel versions:
I've tested with bluedevil 5.22 and bluez-qt 5.85 and still get this, which makes me suspect the regression is somewhere else.
It could be bluez 5.63, released 06.01.2022
Anyone wanna report it to https://github.com/bluez/bluez/issues?
> Anyone wanna report it to https://github.com/bluez/bluez/issues?
In my opinion, it would be nice to repurpose https://github.com/bluez/bluez/issues/272 for this more general problem. That issue has already accumulated a lot of feedback.
That seems to be about something else. I don't get any bluetoothd crashes when I simply turn on Bluetooth, which is all I have to do to reproduce the bug.
It seems that updates in bluez triggered some kind of race condition in user applications, pipewire's wireplumber was also affected, which required to patch pipewire code:
By the way, either restarting plasma or restarting bluetoothd helps.
*** Bug 449679 has been marked as a duplicate of this bug. ***
I notice that bluetooth still functions and devices can connect automatically when none are listed, which explains why restarting plasma and not the bluetooth daemon suffices to repopulate the list. Seems to be a bug in the widget, not bluez.
@Michael D I watch this thread for a while now, and that was also my impression...
However, after yesterdays update, I'm on Arch, it seems fixed. There was no KDE stuff but bluez-5.63-2, linux-5.16.10 and some others.
*** Bug 451016 has been marked as a duplicate of this bug. ***
Can't reproduce. Bluez version is 5.63
On Fedora 35, after upgrade to bluez-5.64-1, works fine.
Still broken for me with Bluez 5.63 and kernel 5.16.14 on Fedora 35. I haven't gotten the 5.64-1 upgrade yet.
Still, it does seem like this is a purely upstream issue. I'll tentatively mark it as such.
(In reply to Nate Graham from comment #19)
> Still broken for me with Bluez 5.63 and kernel 5.16.14 on Fedora 35. I
> haven't gotten the 5.64-1 upgrade yet.
It is in updates-testing repo.
BTW I can also confirm the fix after upgrading to bluez-5.64-1.