Bluetooth will not stay OFF upon resume

[John Saare]

First: apologies for the possibly incorrect package assignment..., but "ubuntu-bug" required I select something.

Second..., this is pasted from two postings I made in Ubuntu Forums...

---

Thinkpad P15gen1, Ubuntu 20.04:

Repeat-by:
Enable BT using the top menu bar dropdown and connect with a BT speaker (a BT stereo adapter in this case).
Play some music..., whatever.
Disable BT using the top menu bar dropdown.
Sleep the machine (close the lid). Note: machine is set to suspend and lock screen upon lid closure.
Wake the machine (open the lid) and unlock screen.
BT is enabled and connects even though it was disabled prior to suspend.

Heh, the funny thing is that BT has been very reliable in every other way.

How do I get BT to stay OFF when I turn it off? (..., and still have it turn on, and work, when I turn it on ).

---

I've spent some time trying to characterize the problem. None of the settings related to power management seemed to relate to the BT failing to stay OFF problem, however..., along the way, I did find another interesting and perhaps related problem:

The following setting:

"Power"->"Power Saving"->"Bluetooth (Bluetooth can be turned off to save power)"->OFF/ON

appears to duplicate the function of the "Bluetooth"->OFF/ON switch setting.

They do the EXACT same thing. They mirror each other.

E.g., when BT is turned on, the BT power save switch will be on. Turn BT off..., and the BT power save switch will turn off.
Now..., turn BT back on, and then turn the BT power save switch off..., the entirety of BT will turn off..., EVEN if there is an active, running connection. Turn the BT power save switch back ON..., and BT will turn back ON.

This is bogus. If the mapping of the GUI functionality to BT settings is broken, it's not a long stretch to think some other mapping or use/management of BT settings is broken as well..., especially since it's in the neighborhood of power management.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gnome-power-manager 3.32.0-2
ProcVersionSignature: Ubuntu 5.8.0-48.54~20.04.1-generic 5.8.18
Uname: Linux 5.8.0-48-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sat Apr 10 12:08:47 2021
DistributionChannelDescriptor:
 # This is the distribution channel descriptor for the OEM CDs
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-sutton-focal-amd64-20201012-119+sutton-simon-focal-amd64+iso
InstallationDate: Installed on 2020-10-22 (170 days ago)
InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20201012-17:03
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-power-manager
UpgradeStatus: No upgrade log present (probably fresh install)

[John Saare (lakester)]

Some observations:

/etc/bluetooth/main.conf:
  AutoEnable is set to "true". This causes BT to be enabled upon boot REGARDLESS of any GNOME
  settings the user might have set. When I set it to "false", I've tried rebooting in these two
  scenarios:

  1. If the GNOME setting is OFF prior to reboot..., BT stays OFF upon reboot.
  2. If the GNOME setting is ON prior to reboot..., BT turns ON upon reboot.

HOWEVER..., in ALL suspend/wake scenarios, regardless of the AutoEnable setting or the GNOME setting, OR even if a "systemctl stop bluetooth" is performed prior to suspend/wake, (or any permutation of all 3)..., BT is re-enabled upon wake.

This SEEMS to be some sort of lack of coordination between systemd configuration and some GNOME component.

[John Saare (lakester)]

Correction: "systemctl stop bluetooth" appears to have more durable results wrt suspend/wake than I first thought, though I thought I tested it pretty thoroughly. If I stop the service..., it appears to stay stopped following suspend/wake. For the moment then, my workaround is to set AutoEnable=false and whenever I want to turn BT off..., do a "systemctl stop bluetooth".

[John Saare (lakester)]

Sigh. So I repeatedly testing suspend/wake following a systemctl stop bluetooth..., and BT stayed off. Until now. I left the machine to sleep for maybe an hour..., just woke it..., boom..., BT is back on. So..., I guess I retract my prior "correction".

[John Saare (lakester)]

So..., I think I figured out why "systemctl stop bluetooth" sometimes works to disable BT thru a suspend/wake cycle, and sometimes not.

If you turn OFF BT using the GNOME settings, regardless of whether or not you do a "systemctl stop bluetooth"..., BT will ALWAYS be turned back ON after a suspend/wake cycle.
If you leave the GNOME BT setting as ON however, and if you do a "systemctl stop bluetooth", BT will stay OFF following a suspend/wake cycle, presumably because the GNOME power management code thinks BT is already ON..., and so takes no action to enable it. Basically..., the left hand doesn't know what the right hand is doing.

My inclination is to pin this bug on the GNOME power management code at this point.

[John Saare (lakester)]

After a little searching around, it seems like the gsd-power plugin is a possible culprit. Again..., apologies if I've miscategorized this bug.

[John Saare (lakester)]

..., or maybe the gsd-rfkill plugin...

[John Saare (lakester)]

Not sure if this is "normal" behavior, but

#dbus-monitor --system "path=/org/bluez/hci0"

returns some interesting output. When BT is shut-off using the Gnome Settings, an event stream is generated that appears to turn it off..., but at the end, seems to tell something, somewhere that it is on.

Pasting from the relevant parts of the output:

signal time=1618356308.901616 sender=:1.548 -> destination=(null destination) serial=237 path=/org/bluez/hci0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.Adapter1"
   array [
      dict entry(
         string "Class"
         variant uint32 0
      )
      dict entry(
         string "Powered"
         variant boolean false
      )
      dict entry(
         string "Discovering"
         variant boolean false
      )
   ]
   array [
   ]

BUT THEN AT THE END OF THE EVENT STREAM...

ethod call time=1618356308.915545 sender=:1.545 -> destination=:1.548 serial=148 path=/org/bluez/hci0; interface=org.freedesktop.DBus.Properties; member=Set
   string "org.bluez.Adapter1"
   string "Discoverable"
   variant boolean true
method call time=1618356308.916566 sender=:1.545 -> destination=:1.548 serial=149 path=/org/bluez/hci0; interface=org.freedesktop.DBus.Properties; member=Set
   string "org.bluez.Adapter1"
   string "DiscoverableTimeout"
   variant uint32 0
method call time=1618356308.916586 sender=:1.545 -> destination=:1.548 serial=150 path=/org/bluez/hci0; interface=org.bluez.Adapter1; member=StartDiscovery
method call time=1618356308.916591 sender=:1.155 -> destination=:1.548 serial=881 path=/org/bluez/hci0; interface=org.freedesktop.DBus.Properties; member=Set
   string "org.bluez.Adapter1"
   string "Powered"
   variant boolean true
method call time=1618356308.916599 sender=:1.40 -> destination=:1.548 serial=509 path=/org/bluez/hci0; interface=org.freedesktop.DBus.Properties; member=Set
   string "org.bluez.Adapter1"
   string "Powered"
   variant boolean true