Created attachment 1215212 [details] GNOME Shell System Menu while a single device is connected Description of problem: This happens usually after suspending the laptop (and sometimes after a GNOME extension crashes which makes all extensions disabled), GNOME Shell System Menu reports Bluetooth always as "Off" though It's already "On" and I've already connected my headset with it. Restarting the Shell (under X.org) solves the issue, but this isn't applicable under Wayland (Default Session). Version-Release number of selected component (if applicable): gnome-shell-3.22.1-2.fc25.x86_64 bluez-5.42-2.fc25.x86_64 bluez-libs-devel-5.42-2.fc25.x86_64 bluez-cups-5.42-2.fc25.x86_64 bluez-obexd-5.42-2.fc25.x86_64 bluez-libs-5.42-2.fc25.x86_64 alsa-plugins-pulseaudio-1.1.1-1.fc25.i686 pulseaudio-libs-9.0-1.fc25.x86_64 alsa-plugins-pulseaudio-1.1.1-1.fc25.x86_64 pulseaudio-libs-glib2-9.0-1.fc25.x86_64 pulseaudio-module-x11-9.0-1.fc25.x86_64 pulseaudio-module-bluetooth-9.0-1.fc25.x86_64 pulseaudio-9.0-1.fc25.x86_64 pulseaudio-libs-9.0-1.fc25.i686 pulseaudio-gdm-hooks-9.0-1.fc25.x86_64 pulseaudio-utils-9.0-1.fc25.x86_64 pulseaudio-module-gconf-9.0-1.fc25.x86_64 How reproducible: Always Steps to Reproduce: 1. Power on your bluetooth device. 2. Suspend your laptop, then wake it up. 3. (Optional) Connect a bluetooth peripheral to your bluetooth. 4. Open GNOME Shell System Menu on the right corner. Actual results: Bluetooth Item displays its status as "Off". Expected results: Bluetooth Item displays its status as "On" or "Connected to 1 Device". Additional info:
Created attachment 1224914 [details] Gnome Shell Invalid Bluetooth Status Option to turn off Bluetooth is available but gnome-shell reports bluetooth to be off.
I can confirm I am experiencing the same issue. Operating System: Fedora 25 (issue present in Fedora 24 also) Laptop: Dell XPS 13 (9350) Network Controller (Bluetooth & WiFi): Intel Corporation Wireless 7265 (rev 59) Navigating to the bluetooth menu while having gnome-control-center in debug mode produces the following log: ============================================================== ** (gnome-control-center:3974): DEBUG: Enabling debugging (gnome-control-center:3974): Bluetooth-DEBUG: Default adapter changed to: (none) (gnome-control-center:3974): bluetooth-cc-panel-DEBUG: Updating airplane mode: BluetoothHasAirplaneMode 1, BluetoothHardwareAirplaneMode 0, BluetoothAirplaneMode 0, AirplaneM ode 0 (gnome-control-center:3974): bluetooth-cc-panel-DEBUG: Default adapter is unpowered, but should be available (gnome-control-center:3974): Bluetooth-DEBUG: New Adapter interface added. (gnome-control-center:3974): Bluetooth-DEBUG: Not adding device 'andy-xps-13' (gnome-control-center:3974): Bluetooth-DEBUG: Not interested in device 'andy-xps-13' (gnome-control-center:3974): Bluetooth-DEBUG: Default adapter changed to: /org/bluez/hci0 ============================================================== Toggling the state of attached devices does not amend this issue however toggling Bluetooth connectivity off and the on does. I'll be keeping a keen eye out to see if I can find what triggers the bug.
Here, toggling the Bluetooth off actually turns off the Bluetooth (rfkill) and hides the Bluetooth menu entirely (as if there's no adapter at all, because in GNOME 3.20, Bluetooth should appear all time even if it's disabled).
I can confirm Bluetooth toggle disappears from the shell when turning Bluetooth off in gnome-control-center. To note: I've been experiencing many other issues with Bluetooth including being unable to connect to devices via the control center (bluetoothctl works fine however).
The combination of (Bluetooth + Pulseaudio + GNOME) always give me headaches when I try to connect my Creative headsets (2 of them, and some unknown headset). The only scenarios that just work: 1. Pair for the first time, 2. and Turn on the headset while bluetooth is On. Other Scenarios that needs some fiddling are: 1. Connecting to an already turned on (and already paired) Bluetooth (through GNOME Control Center > Bluetooth), I should hit the "Connect" toggle multiple times (because it says device is busy in journalctl logs), but it connects after few trials. 2. Switching to A2DP, sometimes it gets stuck (not connected error in journals) and I need to kill pulseaudio (pulseaudio -k) and restart bluetooth.service, to get it working. 3. Connecting to already connected headset to my "Android" phone. It just crashes the whole thing and make my headset goes off. But the other way around works (connecting my laptop first, then connecting my phone). My Creative headsets support multi-point bluetooth connections. But all of this is out of this bug scope :)
Strangely enough I can relate to many of these issues so maybe it's not as out of scope as it seems. Further bluetooth issues I've experienced include: 1. Inability to switch to A2DP on an A2DP supported device. 2. Inability to connect to paired device (although using bluetoothctl rather than gnome settings usually connects fine). Connecting to Bluetooth audio devices may be the source of this issue as my Bluetooth mouse (Microsoft Mouse 3600) and keyboard (Logitech K380) connect automatically 90% of the time.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
A quick "me too" here, up to date F27. In my case this seems to have started/become almost 100% reproducible after a recent bluez update, which added visibility of a bluetooth mouse's power state to the gnome-shell power menu. The mouse reconnects and works after suspend without issues, but in most cases the bluetooth indicator in the system menu shows BT as "off". I can restore the indicator with systemctl restart bluetooth.service. gnome-shell is at 3.26.2-4.fc27 bluez is at 5.48-1.fc27
I think I have a similar issue, but much simpler to detect. It's just that if you plug the Bluetooth USB Adapter after the system has booted, the Bluetooth GNOME panel doesn't show the Bluetooth controller and says "No Bluetooth network found", but on the other side the adapter runs perfectly with bluetoothctl. So GNOME doesn't refresh the Bluetooth hardware. On my case it's on Fedora 28 with a Broadcom USB Adapter.
Created attachment 1479154 [details] Inconsistent bluetooth information in Gnome settings Confirming on Fedora 28, see screenshot.
@Anass Ahmed Can you set the impacted version to Fedora 28, and also raise the issue to Severity "medium" ? (In reply to Benjamin Bellec from comment #9) > On my case it's on Fedora 28 with a Broadcom USB Adapter. Same issue appears with Qualcomm CSR 8510 adapter by the way.
This continues happening in Fedora 29. $ lsusb -v | grep -E 'Bluetooth' ... Bus 001 Device 003: ID 04ca:300b Lite-On Technology Corp. Atheros AR3012 Bluetooth ... $ lspci ... 03:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01) ... $ uname -a Linux x.x 4.20.7-200.fc29.x86_64 #1 SMP Wed Feb 6 19:16:42 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.