I tested this on git-master on a Lenovo Flex laptop and was not able to reproduce.

1. Bluetooth was set to "Restore previous status"
2. Disabled bluetooth and rebooted the laptop, verified that bluetooth was disabled and the icon was grey
3. Observed bluetooth remained disabled during normal laptop usage for 40 minutes

I'll leave this for someone more knowledgeable about bluetooth internals to do more debugging.

Sorry we were not able to figure this one out yet. Coacher, can you still reproduce the issue in Plasma 6.3.4 or later, and also presumably with a newer Kernel version too? I ask because issues like this are often deeper in the software stack.

Thanks a lot!

(In reply to Nate Graham from comment #2)
> Sorry we were not able to figure this one out yet. Coacher, can you still
> reproduce the issue in Plasma 6.3.4 or later, and also presumably with a
> newer Kernel version too? I ask because issues like this are often deeper in
> the software stack.
> 
> Thanks a lot!

Hello.

The issue still occurs from time to time. Last time it was on Plasma 6.3.4 and Fedora 42. Judging from system logs, somethings triggers systemd-rfkill.socket unit, which triggers systemd-rfkill.service, which restores saved rfkill state and enables bluetooth. However, I was unable to find what triggers systemd-rfkill.socket

So it's our Bluetooth service fighting with the rfkill service for control. This makes sense and probably explains the non-determinacy of it.

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

Hi Nate,

thanks for giving attention to this bug, but you might be jumping to conclusions. I have had systemd-rfkill.socket masked since Nov 10, 2022 (can't remember why), and I'm still seeing the problem of bluetooth being active on first login after boot, despite being set to disabled on login.

Other units that may interfere with bluetooth on Fedora 41 are bluetooth.service, triggered by bluetooth.target, and Networkmanager:

mei 12 19:43:12 blackbert NetworkManager[1229]: <info>  [1747071792.8508] Loaded device plugin: NMBluezManager (/usr/lib64/NetworkManager/1.50.3-1.fc41/libnm-device-plugin-bluetooth.so)

Sounds like there's a lot of fighting for control of Bluetooth going on here. :(

Maybe add an option to KDE to do nothing about Bluetooth at startup, keep it as is?

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.

> but afterwards adapter is set to ON, which seems to unblock bluetooth as well and re-enable the whole bluetooth system.

that might be the crucial detail, but it's not entirely clear to me why it matters.

restoreState() has this code:

m_manager->setBluetoothBlocked(GlobalSettings::bluetoothBlocked());

Q_FOREACH (BluezQt::AdapterPtr adapter, m_manager->adapters()) {
        const QString key = QStringLiteral("%1_powered").arg(adapter->address());
        adapter->setPowered(adaptersGroup.readEntry<bool>(key, true));
}

You are suggesting that the setPowered() undoes the setBluetoothBlocked(). That doesn't seem to happen for me, but I'll believe that different hardware might behave differently here.

The part that's weird is that after setBluetoothBlocked(true) all the adapters should disappear, and m_manager->adapters() should be empty. What seems to be the problem is that the list is not empty yet because the DBus traffic from bluez isn't processed yet

A possibly relevant merge request was started @ https://invent.kde.org/plasma/bluedevil/-/merge_requests/219

Any chance you could test if https://invent.kde.org/plasma/bluedevil/-/merge_requests/219 fixes it?

Git commit 76da39982850734ede94ae1453eb90e3fd0d0b70 by Nicolas Fella.
Committed on 25/08/2025 at 10:12.
Pushed by nicolasfella into branch 'master'.

Rework adapter state save/restore

Currently we save the adapter power state, but only when rfkill is not blocked.

When the adapter is saved as powered on, and then we block bluetooth, the saved
state is never changed.

On next startup we then power the adapter on. Apparently on some systems that
results in the rfkill being undone and enables bluetooth when it shouldn't be.

To avoid this

1) Clear the adapter state list on save when bluetooth is blocked
2) Only changed the powered state for adapters where we have remembered a
power state, instead of defaulting to powering it on
Related: bug 507836

M  +5    -1    src/kded/devicemonitor.cpp

https://invent.kde.org/plasma/bluedevil/-/commit/76da39982850734ede94ae1453eb90e3fd0d0b70