kernel 5.1 (is not a regression, goes back to 4.9)
I get anywhere from 1 to 20 bluetooth mouse disconnects per hour, only
when booting Linux. When the same mouse and laptop running Windows 10,
the problem doesn't happen. But I can't tell from the kernel messages
if this is a problem with the mouse drive or the laptop bluetooth
driver. Is there a way to make this more verbose?
[ 1367.387984] flap.local kernel: magicmouse 0005:05AC:030D.0004:
unknown main item tag 0x0
[ 1367.388472] flap.local kernel: input: mouses as
/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/bluetooth/hci0/hci0:512/0005:05AC:030D.0004/input/input20
[ 1367.391109] flap.local kernel: magicmouse 0005:05AC:030D.0004:
input,hidraw2: BLUETOOTH HID v3.06 Mouse [mouses] on 00:c2:c6:f0:52:57
This bug suggests the mouse disconnects when its battery status is
polled by the kernel; if the mouse isn't polled by compiling without
CONFIG_HID_BATTERY_STRENGTH=y then the problem doesn't happen. I can
try that if it's useful information, but I don't think that's the
proper fix. I think the battery polling needs to be fixed instead.
https://bugzilla.kernel.org/show_bug.cgi?id=103631
hci0: Type: Primary Bus: USB
BD Address: 00:C2:C6:F0:52:57 ACL MTU: 1021:4 SCO MTU: 96:6
UP RUNNING PSCAN
RX bytes:15083 acl:0 sco:0 events:2439 errors:0
TX bytes:600912 acl:0 sco:0 commands:2437 errors:0
Features: 0xbf 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'flap.local'
Class: 0x0c010c
Service Classes: Rendering, Capturing
Device Class: Computer, Laptop
HCI Version: 4.2 (0x8) Revision: 0x100
LMP Version: 4.2 (0x8) Subversion: 0x100
Manufacturer: Intel Corp. (2)
Apple Magic Mouse (original, not the 2)
--
Chris Murphy
This is a followup for this bug
https://bugzilla.kernel.org/show_bug.cgi?id=103631
The problem still happens with kernel 5.2.0-rc4 and bluez-5.50-6.fc30.x86_64
When I unset CONFIG_HID_BATTERY_STRENGTH the problem no longer
happens. But as a consequence, there's no information at all about the
mouse's battery strength. So I'd say the original patch is suboptimal.
https://bugzilla.kernel.org/attachment.cgi?id=203881&action=diff
But still better than random disconnects all day long. Any suggestions
on how to collect more information on the device for a better fix?
Chris Murphy
On Sun, 2019-06-09 at 17:22 -0600, Chris Murphy wrote:
> This is a followup for this bug
> https://bugzilla.kernel.org/show_bug.cgi?id=103631
>
> The problem still happens with kernel 5.2.0-rc4 and bluez-5.50-
> 6.fc30.x86_64
>
> When I unset CONFIG_HID_BATTERY_STRENGTH the problem no longer
> happens. But as a consequence, there's no information at all about
> the
> mouse's battery strength. So I'd say the original patch is
> suboptimal.
>
> https://bugzilla.kernel.org/attachment.cgi?id=203881&action=diff
>
> But still better than random disconnects all day long. Any
> suggestions
> on how to collect more information on the device for a better fix?
linux-input@ is probably a more appropriate place to discuss this. Or
at least CC: your bug report there, as the changes would be in the hid
tree.