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

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-settings-daemon in Ubuntu.
https://bugs.launchpad.net/bugs/1923323

Title:
  Bluetooth will not stay OFF upon resume

Status in gnome-settings-daemon package in Ubuntu:
  New

Bug description:
  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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1923323/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to