| Summary: | Bluetooth not enabled after suspend but shown as powered | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-bluez-qt | Reporter: | Robin Green <greenrd> |
| Component: | general | Assignee: | David Rosca <nowrep> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/bluedevil/9c5fda0232bc18148430044b2f73617b6cef12e1 | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
| Attachments: | plasmashell output | ||
|
Description
Robin Green
2016-01-09 03:03:37 UTC
Can you please also send your bluez-qt version? When the bug occurs, please send me the output of these commands: rfkill list qdbus --system org.bluez /org/bluez/hci0 org.bluez.Adapter1.Powered bluez-qt version is kf5-bluez-qt-5.18.0-1.fc23.x86_64
0: tpacpi_bluetooth_sw: Bluetooth
Soft blocked: no
Hard blocked: no
1: tpacpi_wwan_sw: Wireless WAN
Soft blocked: yes
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
4: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
true
That looks fine. I think the issue is only that Bluetooth applet is showing the bad state, so restarting plasmashell should fix it (kquitapp5 plasmashell && plasmashell). Also can you please start plasmashell with "QDBUS_DEBUG=1 plasmashell 2> plasmashell.out", trigger the bug and send the plasmashell.out contents? Created attachment 96651 [details] plasmashell output (In reply to David Rosca from comment #3) > That looks fine. I think the issue is only that Bluetooth applet is showing > the bad state, Yes, you are right. My Bluetooth mouse spontaneously connected again, and yet the applet still shows Bluetooth as disabled. > so restarting plasmashell should fix it (kquitapp5 > plasmashell && plasmashell). Well, a crash fixed it :) > Also can you please start plasmashell with "QDBUS_DEBUG=1 plasmashell 2> > plasmashell.out", trigger the bug and send the plasmashell.out contents? Attached. QDBUS_DEBUG=1 needs to be set for the correct debug logs. There will be a *lot* of messages like plasmashell(589)/(default) unknown: QDBusConnectionPrivate(0x7f8878461e10) got message (signal): QDBusMessage(type=Signal, service=":1.3", p ... Reproduced it myself today. That's fortunate, because QDBUS_DEBUG=1 doesn't work on my machine. Maybe it is something to do with the way the Fedora packages are built. I don't understand why there needs to be 3 bluetooth states: enabled, disabled, and "offline" (the latter implying the applet is disabled but the control panel is not). Is it something in the Bluetooth spec? If not, what purpose does it serve, other than to annoy people? disabled - blocked by rfkill enabled - !disabled = not blocked by rfkill offline - enabled and there is a bluetooth adapter (one or more) and this bluetooth adapter is powered off I'm sorry I didn't fix this issue yet, I was hoping that it will be fixed with Qt 5.6 (QtDBus moved to own thread) because the issue occurs only in plasmashell and not eg. in bluedevil-wizard. In other words, I think the issue only occurs when there is significant dbus traffic. But it wasn't fixed, so I'll need to add workaround. I hope I'll make the fix for 5.21. Git commit 9c5fda0232bc18148430044b2f73617b6cef12e1 by David Rosca. Committed on 15/04/2016 at 07:22. Pushed by drosca into branch 'Plasma/5.6'. Restore adapter powered state after 1s delay Workaround issue in bluez-qt. M +6 -1 src/kded/devicemonitor.cpp http://commits.kde.org/bluedevil/9c5fda0232bc18148430044b2f73617b6cef12e1 |