[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221318

--- Comment #17 from manauer.uel@gmail.com ---
> I could look at it out of curiosity, I think the simplest way is to
> zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0a:00.0
> shortly after it happens, should be enough if the bus isn't very busy.

I attached the zip file. It was captured by connecting the mouse without the
udev rule active and without the dongle, waiting about 10 seconds, then running
your suggested command.

    sudo zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0a:00.0

> Weird. I think the receiver has a different polling rate (1ms?). Do you have
> more mice to check if it's a consistent pattern that things only work if at
> least one 1ms device is connected, or something stupid like that?

This was a surprise. It turns out there are mice that work fine without any
workaround. I swear, the four mice I originally tested were all Logitech plus
one no-name mouse from my partner, and none of them worked, which is why this
did not come up earlier.

    Mouse                               Interfaces  bInterval   Works
    Lenovo USB Optical (17ef:608d)      1           10ms        yes
    Microsoft Comfort 3000 (045e:077b)  1           10ms        yes
    Holtek MGK-15BU (04d9:1135)         1           10ms        yes
    Logitech G5 (046d:c049)             2           1ms/10ms    no
    Logitech G Pro Wireless (046d:c088) 3           1ms/1ms/1ms no (tested via
cable)
    Logitech G403                       ?           ?           no (not at
hand)
    Another no-name mouse (partner's)   ?           ?           no (not at
hand)

The working mice all have a single interface. The failing mice all have
multiple interfaces and at least one endpoint polling at 1ms. The G Pro
Wireless was connected via cable for this test. Its wireless dongle (046d:c539)
was not plugged in during any of these tests. That dongle is the same one that
was observed earlier to make all other mice work when plugged in alongside
them.


> Are you able to run a patched kernel? Lacking better ideas, I suppose we
> could force 1ms polling and see what happens (don't bother with usbhid
> mousepoll option - it doesn't work on xhci-hcd).
Sure, I can try running a patched kernel if you think it is worth it, just for
testing. I would not want to maintain a custom kernel long term, but a one-off
build to confirm a fix is fine. Given the data above though, forcing 1ms might
make things worse rather than better since 1ms seems to be what correlates with
failure. Would forcing 10ms on the failing mice be a more interesting test?


> Maybe, but you suggest to disable a power saving feature everywhere for the
> sake of one old questionable xHCI controller. Maybe there is a better way.
That is a fair point. If there is a more targeted fix, either in the ASM1042A
handling or scoped to the controller rather than all mice, that would obviously
be preferable. I am happy to test whatever approach you think makes more sense.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.