It's annoying isn't it! Do you have any extra device IDs to add or did I 
manage to already find the ones you have?

-- 
  Sent from a phone, apologies for poor formatting.

On 7 September 2024 20:23:43 Marc Espie <marc.espie.openbsd@gmail.com> wrote:

> 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.