[Bug 221318] New: 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

            Bug ID: 221318
           Summary: mice behind ASMedia ASM1042A via Thunderbolt 2 never
                    produce input, most likely due to interrupt pipe idle
                    window during enumeration
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: high
          Priority: P3
         Component: USB
          Assignee: drivers_usb@kernel-bugs.kernel.org
          Reporter: manauer.uel@gmail.com
        Regression: No

This is filed under drivers/usb because the problem involves the interaction
between the usbhid driver, the USB host controller, and the Thunderbolt 2
bridge. The drivers/hid/usbhid subsystem is also directly involved,
specifically the behavior of the interrupt pipe after enumeration. There is no
drivers/thunderbolt component available to select, but the Thunderbolt 2 bridge
appears to be a contributing factor as described below.

On a MacBook Pro 13" Early 2015 (MacBookPro12,1) with an LG UltraWide (34UC98,
internal hub: ASMedia ASM1042A) monitor connected via Thunderbolt 2, USB mice
connected through the monitor's built-in hub never produce any input. This
happens consistently, whether the mouse is plugged in before boot or after. The
mouse is fully enumerated, appears in lsusb, has a correct
/dev/input/by-id/...-event-mouse node, and is recognized by libinput, but no
motion or button events are produced.


# Affected hardware:
- Machine: MacBook Pro 13" Early 2015 (MacBookPro12,1)
- Monitor: LG UltraWide (34UC98), connected via Thunderbolt 2
- USB host controller: ASMedia ASM1042A, PCI ID 1b21:1142
- Affected: any USB mouse connected through the monitor hub
- Not affected: keyboards on the same hub, mice connected to the same monitor
via USB instead of Thunderbolt 2


# Kernel versions tested:
Reproduces on Fedora 43 (6.17), and on a Rawhide kernel (7.0.0-0.rc4). Also
reproduces on CachyOS, Ubuntu and Pop!_OS, so it is not distribution-specific.


# Theory on why this is happening:
After enumeration, the usbhid driver stops submitting interrupt URBs if no
userspace application has opened the device yet. There is a brief idle window
before the desktop environment opens /dev/hidrawX. The ASMedia TT appears to be
sensitive to this idle condition when the hub is accessed through the
Thunderbolt 2 bridge. Once the interrupt pipe goes quiet, the TT most likely
stops delivering input silently and does not recover, even after userspace
opens the device. The same hub connected via USB does not exhibit this
behavior, pointing to the Thunderbolt 2 bridge as a contributing factor. Why
the Thunderbolt 2 bridge makes the difference is not clear to me.

One additional observation worth mentioning: plugging in an unrelated Logitech
wireless receiver into the monitor hub suddenly makes the wired mouse work
(re-plugging needed). The receiver belongs to a completely different wireless
mouse and has no logical connection to the wired mice. It prevents the problem,
though why exactly is unclear. The additional USB traffic it puts on the
controller might be the reason, but I am not sure.

Applying HID_QUIRK_ALWAYS_POLL via the kernel command line fixes the problem
for a specific mouse: usbhid.quirks=0x046d:0xc049:0x00000400

This strongly suggests the problem is the interrupt pipe going idle. As a
generic workaround, holding a file descriptor open on /dev/hidrawX via a udev
rule has the same effect and works for any mouse without needing vendor and
product IDs

Maybe consider keeping the interrupt pipe active by default for all HID mice
until userspace opens the device, or automatically applying
HID_QUIRK_ALWAYS_POLL for mice behind Thunderbolt bridges.

A workaround and write-up are available at:
https://github.com/NextBlaubeere/asmedia-usb-mouse-fix

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

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