Mouse dead behind LG Ultrawide (Thunderbolt 2) on Fedora 43 - Keyboard works fine?

Ask Fedora
, , , ,
1

Hey everyone,

I’m hitting a wall with a weird USB/Thunderbolt issue on my Early 2015 13" MacBook. I just did a clean install of Fedora 43 (Workstation).

My setup: MBP → Thunderbolt 2 cable → LG 34UC98 monitor. I’m using the monitor’s built-in USB ports for my peripherals.

The Problem: The keyboard works perfectly through the monitor, but my mouse (Logitech G5) is completely dead. No movement, no clicks. It has power though and is listed in lsusb and libinput

What I know so far:

  • The mouse works if I plug it directly into the MacBook’s USB port.
  • The mouse works through the monitor on macOS and Windows (dual boot), so it’s not a hardware failure or a bad cable.
  • lsusb actually sees the mouse: Bus 003 Device 007: ID 046d:c049 Logitech, Inc. G5 Laser Mouse.
  • lsusb -t shows it sitting behind the monitor’s nested hubs as a HID device.
  • The kicker: libinput debug-events shows absolutely nothing when I move the mouse.

I’ve already tried:

  1. Switching to Xorg/GNOME Classic (no change).
  2. Checking boltctl. The monitor is authorized and the display/keyboard connected through the same thunderbolt cable are all fine.

Has anyone dealt with mice failing specifically behind Thunderbolt hubs on Linux? I’m not sure where to poke next.

2

Hello. This seems like a problem with the Linux kernel.

I tried Fedora, Bazzite, Mint, CachyOS and Ubuntu and all do have the same behavior.

Does anyone know a place where I can get help with this issue? I really would like to use Linux on my old Macbook Pro.

3

Have you tried https://github.com/pwr-Solaar/Solaar —

Solaar is a Linux manager for many Logitech keyboards, mice, and other devices that connect wirelessly to a Unifying, Bolt, Lightspeed or Nano receiver as well as many Logitech devices that connect via a USB cable or Bluetooth. Solaar is not a device driver and responds only to special messages from devices that are otherwise ignored by the Linux input system.

4

Thanks, but thats not it.

I filed a bug now on bugzilla, if anyone is struggling with the same problem:

5

After more testing I found a reliable fix.

The first clue was that HID_QUIRK_ALWAYS_POLL (value 0x400) applied via the kernel command line fixes the problem for a specific mouse:

usbhid.quirks=0x046d:0xc049:0x00000400

This quirk forces the usbhid driver to keep the interrupt endpoint permanently active. The fact that it works tells me the problem is the interrupt pipe going idle, not a hardware failure. The kernel driver goes quiet after enumeration if nothing in userspace has opened the device yet. There is a brief window before the desktop environment opens the hidraw node during which no interrupt URBs are submitted. Something about the Thunderbolt 2 bridge appears to make the ASMedia TT sensitive to this idle condition in a way that a direct USB connection does not trigger.

The limitation of the quirk approach is that it requires the exact vendor and product ID of every mouse. There is no wildcard support.

I found that holding a file descriptor open on /dev/hidrawX has the same effect as HID_QUIRK_ALWAYS_POLL: it causes usbhid to keep the interrupt pipe active. So instead of the kernel parameter, a udev rule can do this automatically for any mouse the moment its hidraw node appears:

ACTION=="add", SUBSYSTEM=="hidraw", ATTRS{bInterfaceProtocol}=="02", \
    RUN+="/bin/systemd-run --no-block --unit=hid-poll-%k --collect /bin/cat /dev/%k"

bInterfaceProtocol == 0x02 matches any boot-class HID mouse per the USB HID specification. systemd-run launches cat /dev/hidrawX as a transient unit.

I put together a small repository with the rule, an install script, and a detailed write-up: GitHub - NextBlaubeere/asmedia-usb-mouse-fix: Fixes USB mice not working on Linux when connected through an ASMedia ASM1042A USB controller via Thunderbolt 2 · GitHub