https://bugs.kde.org/show_bug.cgi?id=497353
--- Comment #9 from Coacher <[email protected]> --- I believe I have deduced the root cause of the problem. In general, there are 4 different possibilities for bluetooth lock and adapter power: Block Power ------- ------- OFF OFF OFF ON ON OFF ON ON However, the last combination is not possible: adapter cannot be powered ON if block is ON. When restoring state, bluedevil first restores block status, then always restores adapters powers: https://invent.kde.org/plasma/bluedevil/-/blob/v6.4.1/src/kded/devicemonitor.cpp?ref_type=tags#L188 When saving state, bluedevil first saves block status, then if block is OFF bluedevil saves adapter powers: https://invent.kde.org/plasma/bluedevil/-/blob/v6.4.1/src/kded/devicemonitor.cpp?ref_type=tags#L159 The latter and former behavior should be swapped. Consider the following scenario: 1. Block is OFF, adapter is ON, bluedevil saves this state as is. 2. Bluetooth is blocked via tray icon or rfkill or whatever. 3. Block is ON, adapter is OFF, bluedevil saves this state as block is ON, adapter is ON, because of this if clause: https://invent.kde.org/plasma/bluedevil/-/blob/v6.4.1/src/kded/devicemonitor.cpp?ref_type=tags#L165 This is the forth and impossible state from the table above. I can confirm this behavior by looking at .config/bluedevilglobalrc 4. On login bluedevil tries to restore saved state: block is set to ON, but afterwards adapter is set to ON, which seems to unblock bluetooth as well and re-enable the whole bluetooth system. The proposed change: When restoring state, bluedevil should avoid setting adapter powers or connected devices when block is ON. When saving state, bluedevil should properly save adapter powers as OFF if possible, save no connected devices. -- You are receiving this mail because: You are watching all bug changes.
