Bug 493245

Summary:	Bluetooth applet popup sometimes displays "Disconnecting" status while connecting
Product:	[Plasma] plasmashell	Reporter:	cwo <cwo.kde>
Component:	Bluetooth widget	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED FIXED
Severity:	minor	CC:	kde, nate, postix
Priority:	NOR
Version First Reported In:	6.2.4
Target Milestone:	1.0
Platform:	Other
OS:	Linux
Latest Commit:	https://invent.kde.org/plasma/bluedevil/-/commit/d43a562b27213173c260d03d8d1e28b54935a2ae	Version Fixed In:	6.4.0
Sentry Crash Report:

Description cwo 2024-09-17 08:42:33 UTC

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.

Comment 1 cwo 2025-05-13 20:31:13 UTC

*** Bug 504098 has been marked as a duplicate of this bug. ***

Comment 2 Nate Graham 2025-05-13 21:12:53 UTC

Marking as confirmed since someone else is seeing the same thing too.

Comment 3 postix 2025-05-14 18:17:57 UTC

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!

Comment 4 cwo 2025-05-14 18:22:15 UTC

(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.

Comment 5 Kai Uwe Broulik 2025-05-27 16:48:21 UTC

Potential fix: https://invent.kde.org/plasma/bluedevil/-/merge_requests/212

Comment 6 Kai Uwe Broulik 2025-05-27 16:58:10 UTC

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

Comment 7 Kai Uwe Broulik 2025-05-27 17:43:50 UTC

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