SUMMARY I use Bluetooth headphones, so whenever I reboot my laptop I have to remember to tick "Enable Bluetooth" in the system tray to let them connect. It would be very handy to have this checkbox ticked for me by Plasma whenever I log in, to avoid troubleshooting sessions of why headphones don't connect. SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-59.16-default (64-bit)
Heh I have the opposite problem: I generally leave my Bluetooth adapter turned off, but it turns on again on boot! I think we are both suffering from the same problem of the status not being remembered. I did some digging and found that this is controlled by the AutoEnable key in in /etc/bluetooth/main.conf. I found that my config file has AutoEnable=true. Does yours have AutoEnable=false? Regardless, apparently there is no option to remember the status across reboots. But we could potentially add a setting into the bluetooth KCM that manipulates this setting to let you choose whether to enable or not enable the adapter on boot.
(In reply to Nate Graham from comment #1) > I did some digging and found that this is controlled by the AutoEnable key > in in /etc/bluetooth/main.conf. I found that my config file has > AutoEnable=true. Does yours have AutoEnable=false? Apparently openSUSE has no config files for Bluetooth OOTB, but I found how it is possible to create the one you mentioned: https://www.reddit.com/r/openSUSE/comments/eoozm2/bluetooth_on_boot/
Hah, there's a package named "bluez-auto-enable-devices". I guess you want that. Needless to say, this is screaming out in terror/rage for a GUI option in System Settings. :)
I did some investigation. Looking through the source code at https://git.kernel.org/pub/scm/bluetooth/bluez.git/, it would appear that this AutoEnable option is only accessible through the global config file in /etc. There is no option to toggle it at runtime or override a default value in that file with a file in your homedir; in principle this does not make sense anyway since the adapter would already have to be on or off by the time you log in and your homedir becomes accessible. However we can't add a config UI that alters the contents of /etc/bluetooth/main.conf, because that's a distro-provided file, so the changes would simply get overridden with every upgrade to the package that provides it. What we would need is for the feature to dynamically install and remove a package that installs a config file with this property set to true; the default is false, so not having it means the bluetooth adapters do not automatically power up on boot. However this would be dependent on distro packaging. On openSUSE for example, we could install and remove the bluez-auto-enable-devices package. However Fedora provides no such package, and instead simply unconditionally enables the bluetooth adapters by default. Other distros no doubt do other things. Needless to say, implementing the kind of package installer/uninstaller functionality in the KCM that would be necessary to make this wotk would be fragile due to distros changing package names, changing defaults, etc. It would be doable, but messy and incomplete as support would have to be added to every distro that does not currently ship a config file in a package the way openSUSE does. I'm not sure this will be possible to do. :/ Unless you or someone else can think of a smarter option that what I outlined above, this may sadly have to be a RESOLVED CANTFIX. :(
I implicitly phrased my idea in the first comment ("have this checkbox ticked for me"): 1) Plasma knows if Bluetooth is enabled or not 2) Plasma can enable Bluetooth at user's request without touching any config files or packages 3) Plasma can store configuration of whether user wants Bluetooth enabled at session startup (or state at previous session logout) Thus, Plasma already implements all it needs to get this feature to work: upon startup, it can set Bluetooth state as necessary regardless of what's in system config files.
I see, so your proposal is to have a setting which simply overrides the value in the config file, whatever it is. So if AutoEnable=true is set in the config file but we make bluedevil able to do this, then it would simply turn the bluetooth adapter back off again. I suppose that would work, though it would introduce the bug that the value in the systemwide config file would be overridden, making openSUSE's bluez-auto-enable-devices package useless.
Not sure if it's a bug, we already have such behavior for Num Lock: At Plasma startup [ ] On [ ] Off [ ] Do not change
We could do that, though the "do not change" value has proven confusing to users because it implies the existence of a settings hierarchy that most people are not already familiar with.
Hmm, looks like the code already has the ability to save and resume enablement state before and after suspend. I guess we just need to wire that up to login and logout too, in conjunction with this new UI to control what happens. However the save/restore stuff does not seem to be working for me. Need to debug that.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/bluedevil/-/merge_requests/44
Git commit 6557286abe4200f72ab6964079d38f7c7348b13a by Nate Graham. Committed on 12/08/2021 at 15:50. Pushed by ngraham into branch 'master'. Let the user choose Bluetooth status on login Currently there is no way for the user to choose whether Bluetooth is on or off at login. Instead, it is decided automatically for them by the presence or absence of the `AutoEnable=true` key in /etc/bluetooth/main.conf. This is a root-owned file that does not permit user configuration if it is shipped by a distro, because it will be blown away on the next system update. This commit adds a GUI to allow the user to determine the Bluetooth status on login: always enabled, always disabled, or remember the previous status. The default is to remember the previous status, with the initial status on first boot being determined by the distro's default value in the /etc/bluetooth/main.conf config file if present; if not present, bluez's own default value is "disabled". Regardless, thereafter the enablement status on boot will be determined by Bluedevil. Implementation-wise, this is accomplished by adding support in the KDED module for reading a new config file key set by the KCM which controls what do do with Bluetooth when launched. It already has support for saving and restoring status when the system goes to sleep and wakes up; this was extended for shutdown/startup events too. FIXED-IN: 5.23 M +30 -0 src/kcm/bluetooth.cpp M +7 -0 src/kcm/bluetooth.h M +45 -4 src/kcm/package/contents/ui/General.qml M +66 -5 src/kded/devicemonitor.cpp M +3 -0 src/kded/devicemonitor.h https://invent.kde.org/plasma/bluedevil/commit/6557286abe4200f72ab6964079d38f7c7348b13a
(In reply to Nate Graham from comment #8) > We could do that, though the "do not change" value has proven confusing to > users because it implies the existence of a settings hierarchy that most > people are not already familiar with. Its 'Gnomeization' to remove options. We should have "Leave as is" or "Do not change", because some people use other power-saving machinery on laptops. It can also break badly multiuser setups, users who use PAN Bluetooth (instead of WiFi for power saving), or people using services running in background (like MPD, Kodi) and Bluetooth Remotes. So while adding options to change or restore something is nice, I don't see why we cannot keep 4th option "Do nothing" (or however it would be called). I believe if some options is confusing, the problem lies in naming(not option existence). We also have on-hover tooltips to explain each option in details(I think)
Can you come up with a wording that would make sense to a user who does not know about or understand the concept of a settings hierarchy and does not know what the default value that would not be changed happens to be?
(In reply to Nate Graham from comment #13) > Can you come up with a wording that would make sense to a user who does not > know about or understand the concept of a settings hierarchy and does not > know what the default value that would not be changed happens to be? I'm not native english speaker unfortunately, but my propositions for now are: "leave as is" "pre-login state" "always leave current (pre-login) state" "don't care" "whatever it is before login" "do not change" "do nothing on log-in"
Thanks, but the problem with all of those suggestions is that they only make sense if you already have the concept in your mind that multiple parts of the system can affect the same setting, and also if you know what the non-bluedevil default state is.
(In reply to Nate Graham from comment #15) > Thanks, but the problem with all of those suggestions is that they only make > sense if you already have the concept in your mind that multiple parts of > the system can affect the same setting, and also if you know what the > non-bluedevil default state is. It was default for years and not much complained. If user doesn't know what it means, maybe he shouldn't set this option. You can put explanation below what it does. You can even put red bold DISCLAIMER that's this option is not probably what user wants, and to not use it, because it will eat his cat(or something worse will happen), but really: This option is not dangerous. User cannot lose his data, etc. He can lose access to mouse/keyboard(if bluetooth) if he selects 'disable', but not this option. It's stupid to give selection, but remove least invasive option from it, because user may not know/understand. (it's not incomplete selection of options. Some users may even wonder where it is)
Plenty of people complained; that's why this option was added. :) I think the least invasive option is the "remember previous status" one, which is why it's the new default. It's hard for me to imagine a real use case where the user actually wants for Bluetooth to be enabled at login but then they manually turn it off afterwards, or the reverse. Those are the only workflows that would be enabled by adding a "don't change from system's default setting" option. Can you think of any real use cases for doing either of these?
(In reply to Nate Graham from comment #17) > Plenty of people complained; that's why this option was added. :) > > I think the least invasive option is the "remember previous status" one, > which is why it's the new default. It's hard for me to imagine a real use > case where the user actually wants for Bluetooth to be enabled at login but > then they manually turn it off afterwards, or the reverse. Those are the > only workflows that would be enabled by adding a "don't change from system's > default setting" option. Can you think of any real use cases for doing > either of these? I'm not talking about changing default, but not removing(or adding it back as select-able option) previous default state. Even if you don't have use-case for it, there can be others that do. 4 vs 3 options is not much difference, while 4 is complete of selection (you cannot say that +1 option clutters the UI and makes it unreadable). If it doesn't hurt anybody we shouldn't remove it. It's simple. It's KDE vs GNOME philosophy at the core!
I am asserting that the previous default setting (leave it up to the distro's default configuration) was useless. Consider the following use cases: If you wanted bluetooth active at login and your distro configured it to be active at login, you were previously happy, but the new default "remember" setting makes you equally as happy, and you can also be made equally happy by using the new "always on" setting. If you wanted bluetooth inactive at login and your distro configured it to be inactive at login, you were previously happy, but the new default "remember" setting makes you equally as happy, and you can also be made equally happy by using the new "always off" setting. If you wanted bluetooth active at login and your distro configured it to be inactive at login, you were previously unhappy, but you are now happy with the new default "remember" setting, and can also be made happy by using the new "always on" setting. If you wanted bluetooth inactive active at login and your distro configured it to be active at login, you were previously unhappy, but you are now happy with new default "remember" setting, and can also be made happy by using the new "always off" setting. If you wanted the bluetooth status to be remembered, you were previously happy, but you are now happy with the new default "remember" setting. --- I don't believe there are any additional use cases beyond these. We're talking about something as simple as whether bluetooth is on or off at login. There aren't a lot of states it can be in. Thus my assertion that the new feature with its default setting covers all possible states either as good as or better than the old thing. If you can think of any additional use cases not covered here, I'll be happy to consider them. But adding settings to cover theoretical use cases does not make sense, especially when the setting being requested is confusing and needs a paragraph of text to explain it to the majority of users, who after all are generally not familiar with the concept of a settings hierarchy.
The state of the Bluetooth adapter is not restored after logout/login. STEPS TO REPRODUCE 1. Open Bluetooth settings (System Settings > Bluetooth > Settings) 2. Select "Remeber previous status" option 3. Disable Bluetooth adapter 4. Logout and login OBSERVED RESULT Bluetooth adapter in enabled EXPECTED RESULT Bluetooth adapter in disabled SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.23.80 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.3 Graphics Platform: X11
That exact sequence of events produces the correct outcome for me. Can you provide any more information? Any customizations to the system? Is bluedevil running?
Created attachment 143291 [details] Log Can be reproduced on a KDE neon Developer Edition live image with default settings. Attached log in debug mode.
> with default settings Ohh... Can you do a test for me: change the default setting to something else, and see if that setting works for you. Then change it back to the default "Remember" setting, and see if it works now.
Still doesn't work. "Enable Bluetooth" and "Disable Bluetooth" work, but "Remember previous status" doesn't. But I found that the ~/.config/bluedevilglobalrc is empty when the "Remember previous status" is checked. Is that okay?
Yeah, that's fine. It's supposed to work in that case. And it is working for me. I can look into it.
It seems that in the case of "Remember previous status" is checked there must be a parameter bluetoothBlocked in the ~/.config/bluedevilglobalrc. Just checked out, and it works with bluetoothBlocked parameter as it should.
Aha! Okay, I will investigate. Now it makes more sense.
Does it work properly for you only when the config file has `bluetoothBlocked=true` in it? Or does it also work if the config file has `bluetoothBlocked=false` in it?
Yes, it works in both cases. I guess the problem is that saveState () is only called on shutdown and sleep, but not on logout.
Right you are. It listens for sleep or shutdown/reboot, but not logout. Should be an easy fix.
Hmm, there is a "PrepareForShutdown" method, and a "PrepareForSleep" method, but nothing about logout that I can see. Still investigating. However all of this is getting a bit far from the original request, which was implemented. If it has a bug in it, that should ideally be tracked with a seaprate bug report. Can I ask you to file a new bug report that is only about the issue of state not being saved on logout? You can mention whatever details you want from this bug report, and link them using the "See Also" field. Thanks!