Hi folks!
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects. Thanks!
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects.
The problem here is it could be very hardware/firmware dependent, not just for the mouse but the controller as well. I have seen issues across a bunch of BT devices that don't happen on others and that can be very out of our control.
Hi No problem here, Logitech M535 mouse.
On 14-10-2020 19:03, Peter Robinson wrote:
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects.
The problem here is it could be very hardware/firmware dependent, not just for the mouse but the controller as well. I have seen issues across a bunch of BT devices that don't happen on others and that can be very out of our control. _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On 15/10/2020 01:03, Peter Robinson wrote:
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects.
The problem here is it could be very hardware/firmware dependent, not just for the mouse but the controller as well. I have seen issues across a bunch of BT devices that don't happen on others and that can be very out of our control.
I would second that observation.
I've got a Logitech M557 BT Mouse. On an Acer Laptop it will not auto reconnect when the system is rebooted. I have to issue a "bluetoothctl connect" command. However, when the same mouse is used on my HP Tower system it reconnects just fine. This observation is on an F32 KDE spin.
--- The key to getting good answers is to ask good questions.
On 10/14/20 11:33 AM, Adam Williamson wrote:
Hi folks!
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects. Thanks!
Just tested with the KDE compose and some bluetooth headphones. After a suspend / resume (closed then opened laptop lid), I had to manually reconnect the headphones. I'm assuming that's not the expected behavior.
On Wed, Oct 14, 2020 at 9:02 PM Brandon Nielsen nielsenb@jetfuse.net wrote:
On 10/14/20 11:33 AM, Adam Williamson wrote:
Hi folks!
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects. Thanks!
Just tested with the KDE compose and some bluetooth headphones. After a suspend / resume (closed then opened laptop lid), I had to manually reconnect the headphones. I'm assuming that's not the expected behavior.
That depends, audio devices aren't wake up devices like input devices, and on suspend/disconnect the BT headphones may have also gone to sleep.
P
On 10/14/20 3:13 PM, Peter Robinson wrote:
On Wed, Oct 14, 2020 at 9:02 PM Brandon Nielsen nielsenb@jetfuse.net wrote:
On 10/14/20 11:33 AM, Adam Williamson wrote:
[Snip]
Just tested with the KDE compose and some bluetooth headphones. After a suspend / resume (closed then opened laptop lid), I had to manually reconnect the headphones. I'm assuming that's not the expected behavior.
That depends, audio devices aren't wake up devices like input devices, and on suspend/disconnect the BT headphones may have also gone to sleep.
P
They were blinking like they were trying to reconnect. The suspend was only a handful of seconds. If I get a chance, I'll try again with the Gnome compose and see if any of the log messages match the ones in the bug report.
On 10/14/20 3:19 PM, Brandon Nielsen wrote: [Snip]
They were blinking like they were trying to reconnect. The suspend was only a handful of seconds. If I get a chance, I'll try again with the Gnome compose and see if any of the log messages match the ones in the bug report.
Just tried on Gnome, essentially the same behavior. Based on the Bluez discussion elsewhere in this thread I'm going to assume this is just the expected current behavior. So I cannot reproduce the potential blocker with anything convenient to me.
On Wed, 2020-10-14 at 21:13 +0100, Peter Robinson wrote:
On Wed, Oct 14, 2020 at 9:02 PM Brandon Nielsen nielsenb@jetfuse.net wrote:
On 10/14/20 11:33 AM, Adam Williamson wrote:
Hi folks!
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects. Thanks!
Just tested with the KDE compose and some bluetooth headphones. After a suspend / resume (closed then opened laptop lid), I had to manually reconnect the headphones. I'm assuming that's not the expected behavior.
That depends, audio devices aren't wake up devices like input devices, and on suspend/disconnect the BT headphones may have also gone to sleep.
I do actually see a recent upstream commit about this:
https://github.com/bluez/bluez/commit/6611b72600c370ec31795ab48a222594c4afb7...
On Wed, Oct 14, 2020 at 9:21 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2020-10-14 at 21:13 +0100, Peter Robinson wrote:
On Wed, Oct 14, 2020 at 9:02 PM Brandon Nielsen nielsenb@jetfuse.net wrote:
On 10/14/20 11:33 AM, Adam Williamson wrote:
Hi folks!
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects. Thanks!
Just tested with the KDE compose and some bluetooth headphones. After a suspend / resume (closed then opened laptop lid), I had to manually reconnect the headphones. I'm assuming that's not the expected behavior.
That depends, audio devices aren't wake up devices like input devices, and on suspend/disconnect the BT headphones may have also gone to sleep.
I do actually see a recent upstream commit about this:
https://github.com/bluez/bluez/commit/6611b72600c370ec31795ab48a222594c4afb7...
AFAICT that's not fixing a recent regression thought, it seems more of an enhancement for Linux BT audio support as a whole.
I suspect we'll have a new bluez release in the next day or so because of the just announced BleedingTooth [1] vulnerability.
P
Not sure if it's helpful:
Fedora 33 XFCE, so I'm not sure if this information is applicable.
Two Bluetooth mice, "Motorola Bluetooth mouse" and Logitech "Bluetooth Laser Travel Mouse"
Both start up fine after suspend. (Mice left powered on)
Apple Bluetooth mouse a1197 Seems more finicky, did pick back up after suspend. Also left on.
Let me know if other details are desired. I'll do what I can.
On Wed, Oct 14, 2020 at 12:33 PM Adam Williamson adamwill@fedoraproject.org wrote:
Hi folks!
A new proposed blocker bug showed up today: https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend the system, when you resume the bluetooth mouse will not be working any more. You have to go into the GNOME Bluetooth settings applet to get it to work again.
So far we have two reports, but they happened to have the exact same mouse. Can other folks who have bluetooth mice (and even, perhaps, other bluetooth hardware - keyboards, headsets?) - ideally different ones! - please test this and report their findings either here or to the bug? It's important to know what range of hardware this affects. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On Thu, 2020-10-15 at 13:13 -0400, murph nj wrote:
Not sure if it's helpful:
Fedora 33 XFCE, so I'm not sure if this information is applicable.
Two Bluetooth mice, "Motorola Bluetooth mouse" and Logitech "Bluetooth Laser Travel Mouse"
Both start up fine after suspend. (Mice left powered on)
Apple Bluetooth mouse a1197 Seems more finicky, did pick back up after suspend. Also left on.
Let me know if other details are desired. I'll do what I can.
Nope, that's very helpful already! Thanks. We really just need broad data like this, to figure out whether it's affecting all or a wide range of hardware, or if it's more of a limited bug.
I forgot to mention, the laptop is an Acer C710, former Chromebook converted for use with Fedora.
(No normal hardware)
Like I said, let me know if you need other details.
On Thu, Oct 15, 2020 at 1:20 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2020-10-15 at 13:13 -0400, murph nj wrote:
Not sure if it's helpful:
Fedora 33 XFCE, so I'm not sure if this information is applicable.
Two Bluetooth mice, "Motorola Bluetooth mouse" and Logitech "Bluetooth Laser Travel Mouse"
Both start up fine after suspend. (Mice left powered on)
Apple Bluetooth mouse a1197 Seems more finicky, did pick back up after suspend. Also left on.
Let me know if other details are desired. I'll do what I can.
Nope, that's very helpful already! Thanks. We really just need broad data like this, to figure out whether it's affecting all or a wide range of hardware, or if it's more of a limited bug. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Hello:
I've noticed a problem attaching a bluetooth mouse. (or enabling bluetooth at all)
I have a laptop that I don't depend on, and use for testing, or playing around. It's a converted Chromebook, an Acer C710. In the past, I've used bluetooth, primarily for a mouse. Converted it to use the rawhide branch a while ago, and everything seemed OK. My use case for it has changed, so it has spent more time plugged into devices, including a trackball, so I'm not sure exactly when this change happened.
At some point, the bluetooth mouse stopped working, and I was unable to turn on the bluetooth adapter on the laptop at all. I figured that it was my fault, I had done some questionable removals of packages to get things to upgrade. No problem, I'll wipe and reload, and get it working.
While booting off the F33 USB drive, no problem, I was able to use the mouse. Installed, and booted up the system, same.
After I did a full system upgrade, it is back to not working again.
If I boot from an older kernel (the 5.8.15 from the install image) no problem.
If I boot from the 5.10.10, the bluetooth module does not work.
I've seen the same results with KDE, gnome, and XFCE, so I'm pretty sure it's not the DE.
I get the following:
dmesg | grep hci0 [ 11.031856 ] Bluetooth: hci0: don't support firmware rome 0x11020000
Like the following shows: https://bugzilla.kernel.org/show_bug.cgi?id=210681
Not sure where else to go from here, wait until the fix is committed in the kernel?
If a bug report needs to be made, if someone could point me in the right direction.
One irony of this is that I ran the tests for the 5.10 kernel, but never tried to hook up a BT mouse, so I didn't think to mention it.
Thanks, --murph
On Tue, Feb 2, 2021 at 10:42 AM murph nj murphnj+fedora@gmail.com wrote:
If I boot from an older kernel (the 5.8.15 from the install image) no problem.
If I boot from the 5.10.10, the bluetooth module does not work.
I've seen the same results with KDE, gnome, and XFCE, so I'm pretty sure it's not the DE.
I get the following:
dmesg | grep hci0 [ 11.031856 ] Bluetooth: hci0: don't support firmware rome 0x11020000
Like the following shows: https://bugzilla.kernel.org/show_bug.cgi?id=210681
Not sure where else to go from here, wait until the fix is committed in the kernel?
The answer is in comment 19, 20, 25: https://bugzilla.kernel.org/show_bug.cgi?id=210681#c25
The problem with that bug report is too many "me too" comments from people who don't have the same make/model hardware as that bug report. A bug report is both problem *and* hardware specific. When people do me too when they don't have the same hardware as the report, it renders the report useless and will be ignored.
At this point I'd look in linux-bluetooth@ list to see if the person in comment 25 actually pinged the list, and if that email references the author of the commit.
-
Adam Williamson -
Brandon Nielsen -
Chris Murphy -
Ed Greshko -
Jaap Bosman -
murph nj -
Peter Robinson