DevHeads.net

f30 update & bluetooth

I just updated F30 via dnf update.
The kernel in use went from 5.0.13-300.fc30.x86_64 to 5.0.17-300.fc30.x86_64
I regularly use two Bluetooth devices, an aging Microsoft mouse and
Apple Air Pods (ear phones).
Now they are both quite flaky:
While moving, the mouse will connect for a few milli-seconds then
disconnect. This repeats about every ten seconds.
Removing the mouse and re-pairing will allow it to function for at least
some hours but suspend or re-boot and one has to do it again.
The Air Pods did connect but even though selected in the Sound options
the sound still came from the built in speakers (at least once).
Another time they did connect for a while but disconnected when the pc
was idle for a half hour or so.
Boot to the earlier kernel solved these issues.
The pc is a Lenovo X280 thinkpad

Comments

Re: f30 update & bluetooth

By Jeremy Cline at 05/28/2019 - 15:56

Hi,

On 5/28/19 3:26 PM, Wells, Roger K. via devel wrote:
It's quite likely you're hitting a known bug[0], there is a proposed fix
included in 5.1.5 which is currently in updates-testing.

[0] <a href="https://bugzilla.kernel.org/show_bug.cgi?id=203643" title="https://bugzilla.kernel.org/show_bug.cgi?id=203643">https://bugzilla.kernel.org/show_bug.cgi?id=203643</a>

Regards,
Jeremy

Re: f30 update & bluetooth

By Chris Murphy at 05/28/2019 - 15:41

On Tue, May 28, 2019 at 1:27 PM Wells, Roger K. via devel
< ... at lists dot fedoraproject.org> wrote:
I'm having the same problem with a bluetooth mouse. I suspect a user
space regression because with these same kernels (for Fedora 30) used
on Fedora 29 the problem doesn't happen.

If I go to Settings > Bluetooth > double click on device, the
Connection switch is "disabled" and if I set it to "enabled" it
immediately flips back to "disabled" - if I do that about 12-15 times,
finally it sticks and I have a connection.

Bluetooth is right now my #1 complaint. This same laptop and bluetooth
mouse combination works flawlessly under Windows 10. I haven't been
able to isolate which of half dozen things related to Bluetooth are
responsible.

Your case sounds a little different than mine if regression to a
previous kernel fixes the problem. That's very straightforward to
report to the bluetooth list (bugzilla.kernel.org bug reporting system
is not used for bluetooth bugs you have to use the list), although the
optimal way to report it is to do a kernel bisect to prove exactly
which commit (or batch of them) is responsible for the regression.