On Thu, Aug 22, 2024 at 11:30:15AM +0100, Stuart Henderson wrote:
> There's a known firmware bug in some mice where, if the device isn't
> polled regularly, something overflows and the device disconnects and
> reattaches.
> 
> It's quite painful if you have machines in locations where you need
> help to give you information after a startup failure (e.g. failing fsck
> or X not starting for whatever reason), as any useful information soon
> gets replaced with this spam
> 
> wsmouse0 detached
> ums0 detached
> uhidev0 detached
> uhidev0 at uhub0 port 3 configuration 1 interface 0 "PixArt Microsoft USB Optical Mouse" rev 1.10/1.00 addr 2
> uhidev0: iclass 3/1
> ums0 at uhidev0: 3 buttons, Z dir
> wsmouse0 detached
> ums0 detached
> uhidev0 detached
> uhidev0 at uhub0 port 3 configuration 1 interface 0 "PixArt Microsoft USB Optical Mouse" rev 1.10/1.00 addr 2
> uhidev0: iclass 3/1
> ums0 at uhidev0: 3 buttons, Z dir
> wsmouse0 detached
> ums0 detached
> uhidev0 detached
> uhidev0 at uhub0 port 3 configuration 1 interface 0 "PixArt Microsoft USB Optical Mouse" rev 1.10/1.00 addr 2
> uhidev0: iclass 3/1
> ums0 at uhidev0: 3 buttons, Z dir
> (etc.)
> 
> It seems that jcs and kurt figured out a related problem with the
> Surface Type Cover and added UQ_ALWAYS_OPEN in 2021 which is similar
> to linux HID_QUIRK_ALWAYS_POLL and NetBSD UQ_ALWAYS_ON that
> work around this problem.
> 
> Here's a diff to add UQ_ALWAYS_OPEN for the mouse I'm having problems
> with (confirmed to work, and to not affect normal mouse use), plus
> the devices currently listed in NetBSD.
> 
> OK?  (obviously needs 'make' in dev/usb if testing).

I have this happening on most of my usb mice, so very much appreciated.