Bug 377405 - Bluetooth disabled after resume from sleep or hibernate, or startup
Summary: Bluetooth disabled after resume from sleep or hibernate, or startup
Status: RESOLVED FIXED
Alias: None
Product: frameworks-bluez-qt
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.33.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: David Rosca
URL:
Keywords:
: 379107 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-03-09 01:17 UTC by Paul
Modified: 2017-05-26 12:06 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.35


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul 2017-03-09 01:17:01 UTC
After every resume from sleep or hibernate, or after rebooting the system, bluetooth is disabled and has to be re-enabled via the taskbar icon (which also isn't there by default unless you force it to be).

This is an annoyance for me as I use a bluetooth mouse with my laptop, which means that every time I turn on the laptop I'm forced to use the trackpad just to check the box for bluetooth. Bluetooth behaviour is completely normal afterwards however.
Comment 1 David Rosca 2017-03-11 14:36:29 UTC
Can you please post output of "rfkill list" after resume from suspend (when the bluetooth is disabled) and after you manually enable it?
Comment 2 Paul 2017-03-14 21:46:18 UTC
* 1: phy0: Wireless LAN
*         Soft blocked: no
*         Hard blocked: no
* 7: hci0: Bluetooth
*         Soft blocked: no
*         Hard blocked: no

So doesn't look like a driver issue, though I've noticed it seems to remain on after resuming provided the mouse is left on while it sleeps/hibernates, undesired power save feature?
Comment 3 Paul 2017-03-14 22:07:41 UTC
ok there seems to be another part of the bug still where the bluetooth is shown as disabled in the taskbar, but in reality is actually still enabled and accepting connections. Additionally you cannot control the bluetooth via the taskbar icon when its in this state until you open the full manager and manually turn it off and on again.
Comment 4 David Rosca 2017-04-23 10:24:14 UTC
*** Bug 379107 has been marked as a duplicate of this bug. ***
Comment 5 David Rosca 2017-05-26 12:06:22 UTC
Git commit c02c4806c9bfcd6dc36fab6ed9873cff86681cdd by David Rosca.
Committed on 26/05/2017 at 12:05.
Pushed by drosca into branch 'master'.

Fix property changes being missed immediately after an obejct is added

Fix race condition when property changes may be missed if the property
is changed immediately after the object is created.
The issue was that the connection to PropertyChanged signal was
created only after interfacesAdded signal was fired, which may have
already been too late.
This fixes it with connecting to PropertyChanged signal on all paths
in Manager::init().

Differential Revision: https://phabricator.kde.org/D5550

M  +19   -0    autotests/fakebluez/devicemanager.cpp
M  +1    -0    autotests/fakebluez/devicemanager.h
M  +20   -0    autotests/managertest.cpp
M  +1    -0    autotests/managertest.h
M  +0    -8    src/adapter_p.cpp
M  +5    -5    src/device_p.cpp
M  +3    -7    src/input.cpp
M  +0    -4    src/input_p.h
M  +27   -0    src/manager_p.cpp
M  +3    -1    src/manager_p.h
M  +0    -3    src/mediaplayer_p.cpp
M  +7    -0    src/utils.cpp
M  +1    -0    src/utils.h

https://commits.kde.org/bluez-qt/c02c4806c9bfcd6dc36fab6ed9873cff86681cdd