Bug 357720 - Bluetooth not enabled after suspend but shown as powered
Summary: Bluetooth not enabled after suspend but shown as powered
Status: RESOLVED FIXED
Alias: None
Product: frameworks-bluez-qt
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: David Rosca
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-09 03:03 UTC by Robin Green
Modified: 2016-04-15 07:26 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
plasmashell output (63.44 KB, text/plain)
2016-01-15 11:27 UTC, Robin Green
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Green 2016-01-09 03:03:37 UTC
After resuming from suspend, Bluetooth was not working, and the Bluetooth checkbox in the Bluetooth applet in the system tray was both unchecked and greyed out. To fix that I had to go into Bluetooth system settings, and unpower the adapter and click Apply - at which point, it said "your adapter is unpowered" and then I click "fix it". (Incidentally, this was also not enough - to actually get my Bluetooth mouse working again, I also had to disable and re-enable Bluetooth in the Bluetooth applet.)

Reproducible: Always

Steps to Reproduce:
1. Pair with an Apple Magic Mouse
2. Close laptop lid to suspend it
3. After waiting enough time for suspend to complete, open lid
4. Unlock screensaver
5. Open system settings -> Bluetooth -> Adapters

Actual Results:  
Adapter shows as powered on

Expected Results:  
Adapter power status in system settings should reflect actual device power status, as shown in Bluetooth applet in system tray.

The Bluetooth applet was not visible in the system tray after resume, until I toggled the power - I had to click the little arrow to the right of the system tray in order to find it.
Comment 1 David Rosca 2016-01-09 09:31:41 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
Comment 2 Robin Green 2016-01-13 09:12:58 UTC
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
Comment 3 David Rosca 2016-01-13 09:22:11 UTC
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?
Comment 4 Robin Green 2016-01-15 11:27:40 UTC
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.
Comment 5 David Rosca 2016-01-15 17:29:10 UTC
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 ...
Comment 6 David Rosca 2016-01-19 11:48:54 UTC
Reproduced it myself today.
Comment 7 Robin Green 2016-01-20 09:48:38 UTC
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.
Comment 8 Robin Green 2016-03-31 18:15:44 UTC
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?
Comment 9 David Rosca 2016-03-31 18:22:27 UTC
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.
Comment 10 David Rosca 2016-04-15 07:26:05 UTC
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