On Wed, Oct 14, 2020 at 9:21 PM Adam Williamson
<adamwill(a)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(a)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/6611b72600c370ec31795ab48a222594c4a...
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
[1]