Bug 449178 - KCM and Applet no longer show paired devices after turning bluetooth off and on again; have to restart plasmashell or leave/return to the KCM
Summary: KCM and Applet no longer show paired devices after turning bluetooth off and ...
Status: RESOLVED UPSTREAM
Alias: None
Product: Bluedevil
Classification: Plasma
Component: general (show other bugs)
Version: master
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: David Rosca
URL:
Keywords: regression
: 449109 449679 451016 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-01-25 21:33 UTC by Nate Graham
Modified: 2022-04-08 04:19 UTC (History)
17 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2022-01-25 21:33:48 UTC
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


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


EXPECTED RESULT
Applet and KCM device lists are populated with paired devices immediately upon turning on Bluetooth.


ADDITIONAL INFORMATION
`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.
Comment 1 Nate Graham 2022-01-26 17:08:24 UTC
*** Bug 449109 has been marked as a duplicate of this bug. ***
Comment 2 ratijas 2022-01-26 23:38:55 UTC
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™.
Comment 3 Nate Graham 2022-01-27 00:09:10 UTC
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.
Comment 4 ratijas 2022-01-27 11:59:17 UTC
> 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
Comment 5 Michael D 2022-01-29 18:53:18 UTC
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.
Comment 6 Marten 2022-01-30 12:53:28 UTC
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:

- 5.15.16-1
- 5.14.21.2
- 5.10.93-1
- 4.19.225-1
- 4.14.262-1
- 4.4.299-1
Comment 7 Nicolas Fella 2022-01-30 13:13:47 UTC
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
Comment 8 Nate Graham 2022-01-31 18:23:44 UTC
Anyone wanna report it to https://github.com/bluez/bluez/issues?
Comment 9 ratijas 2022-01-31 19:06:33 UTC
> 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.
Comment 10 Nate Graham 2022-01-31 19:16:19 UTC
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.
Comment 11 valdikss 2022-01-31 20:46:41 UTC
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:
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/159
Comment 12 valdikss 2022-01-31 20:47:03 UTC
By the way, either restarting plasma or restarting bluetoothd helps.
Comment 13 kde 2022-02-06 02:49:04 UTC
*** Bug 449679 has been marked as a duplicate of this bug. ***
Comment 14 Michael D 2022-02-18 08:33:06 UTC
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.
Comment 15 Lothar 2022-02-23 09:54:26 UTC
@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.
Comment 16 Nicolas Fella 2022-03-01 22:46:41 UTC
*** Bug 451016 has been marked as a duplicate of this bug. ***
Comment 17 Fushan Wen 2022-03-22 08:13:37 UTC
Can't reproduce. Bluez version is 5.63
Comment 18 Pawel 2022-03-22 08:33:27 UTC
On Fedora 35, after upgrade to bluez-5.64-1, works fine.
Comment 19 Nate Graham 2022-03-23 19:14:19 UTC
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.
Comment 20 Pawel 2022-03-24 18:52:15 UTC
(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.
Comment 21 Nate Graham 2022-04-08 04:19:47 UTC
BTW I can also confirm the fix after upgrading to bluez-5.64-1.