GNOME Bugzilla – Bug 638117
Remember off/on state between sessions
Last modified: 2018-01-29 08:48:12 UTC
I never use bluetooth, so I turn it off to save battery, but I have to do this everytime I log in. gnome-bluetooth should just remember the state from the last session. For the record is this the behaviour in mac osx. Not sure about windows.
This bug still affects the bluetooth setting in Gnome 3.2. It is also difference / inconsistent behaviour from the sound and the wireless/network manager, which will remember their settings across sessions. Can we set this bug to confirmed and priority low? gnome-bluetooth version 3.2.0 on x86_64 on F16
(In reply to comment #1) > Can we set this bug to confirmed and priority low? Bugs are rarely marked as confirmed in GNOME, but that doesn't mean developers won't fix them. And usually priorities are not really used either. So we just need to hope somebody jumps in, or do it ourselves...
There's also a bug about it here: https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/848798
Bastien, where do you think the GSettings schema should live? AFAICT, there's no Bluetooth daemon that could handle this: the GNOME Shell indicator or the gnome-panel applet would have to read that setting and act accordingly. Should we add this to gsettings-desktop-schemas, or to gnome-settings-daemon?
*** Bug 659221 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Bastien, where do you think the GSettings schema should live? Nowhere, gnome-bluetooth stores _nothing_. > AFAICT, there's > no Bluetooth daemon that could handle this: There is, it's bluetoothd.
Ah, so you mean that's a bluez bug, not a gnome-bluetooth one?
With some investigation, I found that in /etc/bluetooth/main.conf, there's already such an option: # What value should be assumed for the adapter Powered property when # SetProperty(Powered, ...) hasn't been called yet. Defaults to true InitiallyPowered = true There's also an option I don't really understand: # Remember the previously stored Powered state when initializing adapters RememberPowered = true These map resp. to main.mode and main_opts.remember_powered property when loading. So one solution would simply be saving main.mode on quit to InitiallyPowered. But ATM the config file is read-only, so I'm not sure devs would think it's the right solution. I'll mail linux-bluetooth about that.
Do you really think I would have left this open if the bug was solely in bluez?
I thought you were leaving me the honor of doing it myself... ;-) Do you want to work on this, you do you prefer to give me some pointers?
Do you have hardware with a hardware killswitch? If not, you probably won't be able to reproduce bugs with the adapter not getting into a state where the power can be resumed to it (eg. it would be impossible to turn Bluetooth back on). That's why SetPower is called in the Bluetooth applet and the properties (as could be gathered from the git logs). Feel free to give it a try, but me fixing it and me fixing it are about as much work, so I'm not sure it's worth your time, unless you can do all the legwork on documenting the exact circumstances of the bug.
(In reply to comment #11) > Do you have hardware with a hardware killswitch? If not, you probably won't be > able to reproduce bugs with the adapter not getting into a state where the > power can be resumed to it (eg. it would be impossible to turn Bluetooth back > on). I don't have a hardware switch, but indeed I experienced bugs where I couldn't bring Bluetooth and WiFi on after kernel crashes. > That's why SetPower is called in the Bluetooth applet and the properties (as > could be gathered from the git logs). Feel free to give it a try, but me fixing > it and me fixing it are about as much work, so I'm not sure it's worth your > time, unless you can do all the legwork on documenting the exact circumstances > of the bug. I don't understand the relation with the present report. I thought it was just a matter of adding a setting somewhere. I don't really use Bluetooth, so indeed I'm quite clueless and not of much help if that's more complex than that...
On my laptop there is a kill switch that kills both bluetooth and wireless, but not individually. There is also a special fn key that just disables and enables wireless. There is no bluetooth special fn key. I'd be happy to help with the testing and troubleshooting.
*** Bug 662649 has been marked as a duplicate of this bug. ***
*** Bug 664448 has been marked as a duplicate of this bug. ***
I also have a laptop with Bluetooth without ever using it. Yet in Fedora 16 with GNOME 3.2 the Bluetooth hardware is enabled by default when I log in, unlike some other distributions which require me to activate it manually. While this bug is not yet fixed, is there any workaround to disable the initialization of the Bluetooth hardware?
@devs: Gnome's bluetooth applet should get a bluetooth device's on/off status through dbus from SetProperty setting sent by bluetoothd [1].This bug is also reported to LP [2]. [1] http://permalink.gmane.org/gmane.linux.bluez.kernel/4302 [2] https://bugs.launchpad.net/bugs/446657
(In reply to comment #9) > Do you really think I would have left this open if the bug was solely in bluez? You rejected this as a Gnome bug at https://bugzilla.gnome.org/show_bug.cgi?id=598140#c1
*** Bug 671476 has been marked as a duplicate of this bug. ***
*** Bug 672511 has been marked as a duplicate of this bug. ***
*** Bug 681982 has been marked as a duplicate of this bug. ***
*** Bug 682085 has been marked as a duplicate of this bug. ***
Ok, 1 year 8 months is enough talk. Time to try some code.
Created attachment 221616 [details] [review] Allow external management of the Powered state Since the Powered property is remembered across reboots by bluetoothd, it should be the primary way to enable and disable bluetooth adapters in the applet.
Created attachment 221617 [details] [review] Bluetooth: use the new powered property instead of killswitch BluetoothApplet now exposes the powered property from bluetoothd. Use that instead of going to the rfkill directly, as it is remembered across reboots. This is a semi-experimental patch against gnome-shell to use the new API. In local testing it seems to work. If nothing breaks too hard, I'll prepare a patch for the fallback applet and gnome-control-center too.
Review of attachment 221616 [details] [review]: ::: applet/bluetooth-applet.c @@ +1037,3 @@ g_object_class_install_property (gobject_class, PROP_DISCOVERABLE, properties[PROP_DISCOVERABLE]); + properties[PROP_POWERED] = g_param_spec_boolean ("powered", Why do you invent a new property when we already have "default-adapter-powered"? If the goal is to handle the powered property for _all_ the adapters (which it should), then the documentation is wrong.
Review of attachment 221617 [details] [review]: Except that handling the powered should be the exact same thing as poking the soft killswitch associated with the adapter. See bluez/src/rfkill.c
Not really, as far as I understand that code: it only reacts to unblocks, and sets the configured powered state to the device. We want to do the opposite: change the stored configuration when the rfkill changes, or if that's not possible/desirable, change the powered state on the device in a way that bluetoothd will remember for the next reboot.
It appears that this bug can also be fixed by an upstart script for rfkill. Please see https://bugs.launchpad.net/bugs/1073669 for more details. I haven't tested that script so I don't know if it fixes this bug too.
*** Bug 691833 has been marked as a duplicate of this bug. ***
Updating the bug. We'll probably need to go through this once more, as bluetoothd does not restore power to the adapter anymore in BlueZ 5. We might want to use a simple script to save/restore power (like we do for sound devices), rather than having to do this in a user session.
(In reply to comment #0) > I never use bluetooth, so I turn it off to save battery, but I have to do this > everytime I log in. gnome-bluetooth should just remember the state from the > last session. > > For the record is this the behaviour in mac osx. Not sure about windows. same here, debian wheezy 7.1, amd64
(In reply to comment #32) > same here, debian wheezy 7.1, amd64 That's useless information without gnome-bluetooth *version info* (no idea which version is run by random distro X out there). Please provide version info if you run a recent version, please refrain from commenting if you run some older version (3.4 or below as it's not interesting). Thanks! :)
I'd like to second comment #0. Using updated Fedora 19 with GNOME 3.8: gnome-bluetooth-3.8.1-1.fc19.x86_64 bluez-4.101-9.fc19.x86_64 dmesg: toshiba_bluetooth: Detected Toshiba ACPI Bluetooth device - installing RFKill handler I "fixed" that by blacklisting toshiba_bluetooth.ko. But would appreciate more elegant way to disable bluetooth.
Is there any fix for this issue? $ rpm -qa | grep blue bluez-libs-4.101-9.fc19.x86_64 mate-bluetooth-libs-1.6.0-5.fc19.x86_64 gnome-bluetooth-3.8.2.1-1.fc19.x86_64 gnome-bluetooth-libs-3.8.2.1-1.fc19.x86_64 mate-bluetooth-1.6.0-5.fc19.x86_64 bluez-4.101-9.fc19.x86_64 blueman-nautilus-1.23-6.fc19.x86_64 blueman-1.23-6.fc19.x86_64 bluez-cups-4.101-9.fc19.x86_64 pulseaudio-module-bluetooth-3.0-10.fc19.x86_64
(In reply to comment #35) > Is there any fix for this issue? Maybe, and at the right level (which isn't the session level at which gnome-bluetooth works). The upcoming systemd 209 saves and reapplies rfkill statuses to devices on boot. That might be enough to fix the issue but would need testing.
Still seeing this in gnome 3.10.2 In addition, the status panel (top right corner) now shows bluetooth as off even when it's on. Switching it off in the settings > bluetooth shows up in this panel as "airplane mode".
I have a Lenovo Thinkpad T500 with Debian and my solution is the following file /etc/modprobe.d/rfkill.conf: options rfkill master_switch_mode=0 With that option it remembers the last state over reboots which could be due to thinkpad_acpi.
I'm seeing this with gnome-bluetooth 3.12.9 and bluez 5.17 from Debian experimental on a Thinkpad X201t.
I am having this issue on Ubuntu 14.04 with bluez 4.101-0ubuntu13 and gnome-bluetooth 3.8.2.1-0ubuntu4 and not sure it matters but I also have indicator-bluetooth 0.0.6+14.04.20140207-0ubuntu2. I got this with a dpkg-query -l "*blue*" in case anyone else is wondering what versions they are running. Bastien, I can donate some testing time, some hardware (a laptop with a hardware kill switch?) and or round up some funds to dedicate time to focus on this if it would help the Gnome developers.
There is no testing time required really, any modern systemd-enabled OS has this feature working out of the box (this includes Fedora 21, Arch and maybe Mageia), and any user with any of those systems can confirm. Given that systemd provides this feature, I don't think we'll implement it at the GNOME layer, meaning that Ubuntu and Debian users should just wait until their distribution also adopts it.
*** Bug 598140 has been marked as a duplicate of this bug. ***
(In reply to comment #41) > There is no testing time required really, any modern systemd-enabled OS has > this feature working out of the box (this includes Fedora 21, Arch and maybe > Mageia), and any user with any of those systems can confirm. > This does **not** work on Fedora 20 + systemd, with GNOME 3.12. Also, I don't know why this bug is closed...
(In reply to comment #43) > (In reply to comment #41) > > There is no testing time required really, any modern systemd-enabled OS has > > this feature working out of the box (this includes Fedora 21, Arch and maybe > > Mageia), and any user with any of those systems can confirm. > > > > This does **not** work on Fedora 20 + systemd, with GNOME 3.12. See comment 38, if you're using a Thinkpad. > Also, I don't know why this bug is closed... Because the functionality is implemented in systemd's systemd-rfkill utility (see "man systemd-rfkill"). If it doesn't work, please file a bug against systemd at https://bugs.freedesktop.org
Could you explain that a bit further? The man page for rfkill and http://wireless.kernel.org/en/users/Documentation/rfkill both suggest rfkill deals with the state of hardware switches. However, this issue isn't limited to systems with a physical kill switch. In fact, the first reports don't mention physical switches at all. I can confirm that on my system - a thinkpad without a physical switch running Fedora 20, Gnome 3.10.2 - the bluetooth setting (the virtual switch in the gnome settings panel) is set to "on" after every reboot.
(In reply to comment #45) > Could you explain that a bit further? This really isn't the place to do that. > The man page for rfkill and > http://wireless.kernel.org/en/users/Documentation/rfkill both suggest rfkill > deals with the state of hardware switches. And software rfkills. > However, this issue isn't limited to > systems with a physical kill switch. In fact, the first reports don't mention > physical switches at all. That would be because we can't control hardware rfkill switches in software. Not without building a robot. > I can confirm that on my system - a thinkpad without a physical switch running > Fedora 20, Gnome 3.10.2 - the bluetooth setting (the virtual switch in the > gnome settings panel) is set to "on" after every reboot. I don't think I can be clearer than comment 44. If it doesn't work, file a bug against systemd. But it's most likely going to be a kernel bug as per comment 38.
Comment 41 mentioned it was fixed in F21, *not* in F20.
(In reply to comment #47) > Comment 41 mentioned it was fixed in F21, *not* in F20. Exactly, Fedora 20 has systemd 208 + bugfixes, but you need systemd 209 or better to have the rfkill functionality. It *is expected* not to work on Fedora 20, unless you manually backport a newer systemd (something I did while I was using F20, but I do not recommend) (The 3.12 copr does not include systemd, so GNOME 3.10 or 3.12 does not matter) Fedora 21 has systemd 215 (right now), so this works.
Thanks for the recent comments everyone. So to confirm, Ubuntu needs to adopt systemd 209 or greater and then it might/should start working for everyone? p.s. If you use Ubuntu... "systemd is under active development in Ubuntu although the rough plan would be to default to systemd sometime in the 14.10/15.04 timeframe." https://wiki.ubuntu.com/systemd#Warning.21_Experimental_code
(In reply to comment #49) > So to confirm, Ubuntu needs to adopt systemd 209 or greater and then it > might/should start working for everyone? Yeah.
Just a note that might interest future visitors: I'm experiencing the problem described in this bug on a Dell laptop running Fedora 22, and it looks like a systemd bug: https://bugzilla.redhat.com/show_bug.cgi?id=1259197