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
