SUMMARY There is a period during the connecting process when the connection is not fully established (and the headphones have not played the "connected" sound yet), but the internal state is already switched to connected (and the device appears in the "connected" part on top of the listview, rather than among all the unconnected devices). When this happens, the applet displays the very confusing status "Disconnecting" even though the connection is still being fully established. This is very confusing. This is barely noticable when disconnecting then reconnecting (though if you pay attention, it still happens), but the first connection after resuming from suspend (and possibly startup, will need to test separately) seems to be stuck in this state for longer, making it quite apparent. STEPS TO REPRODUCE 1. Connect to BT headphones, then suspend the computer 2. Resume from suspend, open the bluetooth applet (where the headphones should be disconnected) 3. Press the connect button for these headphones OBSERVED RESULT The status for the headphones displays "Connecting", then moves to the connected devices section of the list view and displays "Disconnecting" until finally settling on "Connected". EXPECTED RESULT The status should read "Connecting" until it's "Connected", with no "Disconnecting" in between. Operating System: TUXEDO OS 3 KDE Plasma Version: 6.1.90 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.8.0-101041-tuxedo (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 520 ADDITIONAL INFORMATION I'm not sure if this only happens with headphones or also non-audio devices, can't easily test this right now. Will try to add a screen recording later, but need to reboot as I was testing something under X11.
*** Bug 504098 has been marked as a duplicate of this bug. ***
Marking as confirmed since someone else is seeing the same thing too.
In the case of my headphones + Asus BT500 adapter: > This is barely noticable when disconnecting then reconnecting - For me it's always noticeable when disconnecting and re-connecting > On slow machines I wouldn't describe my machine as slow (5900X, 32 GB RAM, NVMe) If you need more information, please let me know!
(In reply to postix from comment #3) > In the case of my headphones + Asus BT500 adapter: > > This is barely noticable when disconnecting then reconnecting > - For me it's always noticeable when disconnecting and re-connecting > > > On slow machines > I wouldn't describe my machine as slow (5900X, 32 GB RAM, NVMe) > > If you need more information, please let me know! Quite likely the BT adapter, driver, and device you're connecting to also matter. Maybe fully re-establishing connection is faster on some devices than others, would make sense.
Potential fix: https://invent.kde.org/plasma/bluedevil/-/merge_requests/212
Git commit d92a6f12d85f052fd4c71c6b63fa170e4a09cfee by Kai Uwe Broulik. Committed on 27/05/2025 at 16:55. Pushed by broulik into branch 'master'. DevicesStateProxyModel: Split disconnecting into a dedicated state While the method "registerPendingCall" sounds generic, it's really only about the connecting state. Unfortunately, a device can be considered connected before the pending call has finished. This causes the UI to briefly display a "Disconnecting" in the UI which is confusing. By properly tracking connecting and disconnecting calls we can ensure that the device state displayed matches expectations. M +72 -8 src/applet/devicesstateproxymodel.cpp M +10 -2 src/applet/devicesstateproxymodel.h M +12 -8 src/applet/package/contents/ui/DeviceItem.qml M +1 -1 src/applet/package/contents/ui/main.qml https://invent.kde.org/plasma/bluedevil/-/commit/d92a6f12d85f052fd4c71c6b63fa170e4a09cfee
Git commit d43a562b27213173c260d03d8d1e28b54935a2ae by Kai Uwe Broulik. Committed on 27/05/2025 at 17:37. Pushed by broulik into branch 'Plasma/6.4'. DevicesStateProxyModel: Split disconnecting into a dedicated state While the method "registerPendingCall" sounds generic, it's really only about the connecting state. Unfortunately, a device can be considered connected before the pending call has finished. This causes the UI to briefly display a "Disconnecting" in the UI which is confusing. By properly tracking connecting and disconnecting calls we can ensure that the device state displayed matches expectations. (cherry picked from commit d92a6f12d85f052fd4c71c6b63fa170e4a09cfee) Co-authored-by: Kai Uwe Broulik <kde@privat.broulik.de> M +72 -8 src/applet/devicesstateproxymodel.cpp M +10 -2 src/applet/devicesstateproxymodel.h M +12 -8 src/applet/package/contents/ui/DeviceItem.qml M +1 -1 src/applet/package/contents/ui/main.qml https://invent.kde.org/plasma/bluedevil/-/commit/d43a562b27213173c260d03d8d1e28b54935a2ae