search

sriemer / fix-linux-mouse

Hints how to fix USB mouse issues on Linux
44 stars 5 forks source link

Collecting further mice and other HID devices with disconnect issues 2024+ #28

Open sriemer opened 6 months ago

sriemer commented 6 months ago

I've fixed several USB HID devices at upstream Linux kernel with HID_QUIRK_ALWAYS_POLL (0x00000400) already.

So please let me know if your mouse or USB HID device disconnects every x seconds or every minute when no user-space driver is running and nothing polls it this way (usually mice on a virtual terminal [VT] without gpm running).

Please test if the kernel boot option

usbhid.quirks=0xaaaa:0xbbbb:0x00000400

fixes the issue while aaaa is the USB vendor ID and bbbb is the USB product ID in hex from lsusb or lsusb -vvv output.

If this fixes your issue, please let me know the USB IDs, your mouse or device model, your kernel version, and which distro you use.

I will check if it has been fixed at the latest upstream kernel already and prepare the kernel patch if needed.

Thanks in advance!

cboin1996 commented 3 months ago

@sriemer I am using Arch

I have tried adding the following to my ODDOR handbrake modprobe conf: options usbhid quirks=0x1021:0x8888:0x00000400

but the handbrake does not show up in DIRT 2.0.

a quick lsusb shows:

Bus 001 Device 004: ID 1021:8888 STC ODDOR-HANDBRAKE

cboin1996 commented 3 months ago

@sriemer I have a razer leviathan v2 pro soundbar that would keep re-connecting if I tried to use USB mode.

I added to my grub cfg: usbhid.quirks=0x1532:0x0548:0x00000400 and ran sudo grub-mkconfig -o /boot/grub/grub.cfg.

I restarted, and now it stays connected (doesn't make sound but thats another issue im sure -- for now I can just use bluetooth.

OS: Arch Linux x86_64 
Host: MS-7B50 1.0 
Kernel: 6.7.8-arch1-1
sriemer commented 2 months ago

STC ODDOR-HANDBRAKE

Thanks for reporting @cboin1996. Sorry for the delay here. I'm swamped with work and I'm mostly working with GitHub Enterprise now. So I don't look here frequently recently. Is this device detected as a USB HID v1.11 Joystick at all? Please provide the relevant kernel log part and full lsusb -vvv output regarding this device. TIA

What I'm thinking here is that they might have created a new firmware which requires a special driver. Have you checked if you can download a special driver?

sriemer commented 2 months ago

@sriemer I have a razer leviathan v2 pro soundbar that would keep re-connecting if I tried to use USB mode.

  • lsusb shows: Bus 001 Device 008: ID 1532:0548 Razer USA, Ltd Razer Leviathan V2 Pro

I added to my grub cfg: usbhid.quirks=0x1532:0x0548:0x00000400 and ran sudo grub-mkconfig -o /boot/grub/grub.cfg.

I restarted, and now it stays connected (doesn't make sound but thats another issue im sure -- for now I can just use bluetooth.

@cboin1996 Great to hear that you have a workaround. Audio devices shouldn't be detected as USB HID devices. So I guess this device has to go into the "needs special driver" list so that USB HID ignores it. Have you checked if there is a separate Linux driver for this one? TIA

Clutchnp commented 1 month ago

@sriemer Works on arch with cooler master mice 2.4ghz mode 

    distro ⏹ Arch Linux
    kernel ⏹ 6.9.2-arch1-1
sriemer commented 1 month ago

Works on arch with cooler master mice 2.4ghz mode

@Clutchnp Is this the MM712?

It is expected that wireless mice work as expected with the wireless connection because the usbhid driver is not involved at all. Be aware of the health consequences of wireless communication. I'm rather interested in USB connected usbhid devices. Please provide the related dmesg output when connecting the device via USB cable. I'm only interested in devices disconnecting themselves every 30s or every minute on a virtual terminal (pressing Ctrl + Alt + F1 usually enters such a virtual terminal). This can be super annoying when trying to fix a completely different issue such as a systemd start up issue. Thanks in advance.

Clutchnp commented 1 month ago

@sriemer

Works on arch with cooler master mice 2.4ghz mode

@Clutchnp Is this the MM712?

It is expected that wireless mice work as expected with the wireless connection because the usbhid driver is not involved at all. Be aware of the health consequences of wireless communication. I'm rather interested in USB connected usbhid devices. Please provide the related dmesg output when connecting the device via USB cable. I'm only interested in devices disconnecting themselves every 30s or every minute on a virtual terminal (pressing Ctrl + Alt + F1 usually enters such a virtual terminal). This can be super annoying when trying to fix a completely different issue such as a systemd start up issue. Thanks in advance.

  1. Yes this is the mm712
  2. You are wrong in the aspect that this doesn't effect wireless mice as the 2.4ghz dongle is treated as a usb mice which uses the usbhid driver this can be verified using `hwinfo --mouse' 
    31: USB 00.1: 10503 USB Mouse
[Created at usb.122]
Unique ID: xnLL.CpI3AkGamfF
Parent ID: k4bc.2DFUsyrieMD
SysFS ID: /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1
SysFS BusID: 1-4:1.1
Hardware Class: mouse
Model: "Cooler Master Mice Dongle"
Hotplug: USB
Vendor: usb 0x2516 "Cooler Master Co., Ltd."
Device: usb 0x01b7 "Cooler Master Mice Dongle"
Revision: "1.55"
Compatible to: int 0x0210 0x0048
Driver: "usbhid"
Driver Modules: "usbhid"
Device File: /dev/input/mice (/dev/input/mouse0)
Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event14, /dev/input/by-id/usb-COOLER_MASTER_Cooler_Master_Mice_Dongle-if01-event-mouse, /dev/input/by-path/pci-0000:00:14.0-usbv2-0:4:1.1-event-mouse, /dev/input/by-path/pci-0000:00:14.0-usb-0:4:1.1-event-mouse, /dev/input/by-path/pci-0000:00:14.0-usb-0:4:1.1-mouse, /dev/input/by-id/usb-COOLER_MASTER_Cooler_Master_Mice_Dongle-if01-mouse, /dev/input/by-path/pci-0000:00:14.0-usbv2-0:4:1.1-mouse
Device Number: char 13:63 (char 13:32)
Speed: 12 Mbps
Module Alias: "usb:v2516p01B7d0155dc00dsc00dp00ic03isc01ip02in01"
Driver Info #0:
Buttons: 8
Wheels: 4
XFree86 Protocol: explorerps/2
GPM Protocol: exps2
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #45 (Hub)
    1. When connected via the USB cable, I did not experience the disconnect issue. However, when utilizing wireless mode with the dongle, I encountered it. I have included both relevant dmesg outputs, one for the dongle and one for the USB cable, in this response 
      ** with the usb cable**
[109949.854643] usb 1-4: new full-speed USB device number 45 using xhci_hcd
[109949.996656] usb 1-4: New USB device found, idVendor=2516, idProduct=0169, bcdDevice= 2.62
[109949.996670] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[109949.996676] usb 1-4: Product: MM712 Hybrid Mouse
[109949.996681] usb 1-4: Manufacturer: COOLER MASTER
[109950.002044] input: COOLER MASTER MM712 Hybrid Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/0003:2516:0169.002C/input/input69
[109950.062118] hid-generic 0003:2516:0169.002C: input,hidraw0: USB HID v1.11 Keyboard [COOLER MASTER MM712 Hybrid Mouse] on usb-0000:00:14.0-4/input0
[109950.063886] input: COOLER MASTER MM712 Hybrid Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:2516:0169.002D/input/input70
[109950.064327] hid-generic 0003:2516:0169.002D: input,hidraw1: USB HID v1.11 Mouse [COOLER MASTER MM712 Hybrid Mouse] on usb-0000:00:14.0-4/input1
[109950.066067] input: COOLER MASTER MM712 Hybrid Mouse Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.2/0003:2516:0169.002E/input/input71
[109950.121721] input: COOLER MASTER MM712 Hybrid Mouse System Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.2/0003:2516:0169.002E/input/input72
[109950.122065] hid-generic 0003:2516:0169.002E: input,hidraw2: USB HID v1.11 Device [COOLER MASTER MM712 Hybrid Mouse] on usb-0000:00:14.0-4/input2
[109950.123786] hid-generic 0003:2516:0169.002F: hiddev96,hidraw3: USB HID v1.11 Device [COOLER MASTER MM712 Hybrid Mouse] on usb-0000:00:14.0-4/input3
[109950.125368] hid-generic 0003:2516:0169.0030: hiddev97,hidraw4: USB HID v1.11 Device [COOLER MASTER MM712 Hybrid Mouse] on usb-0000:00:14.0-4/input4

      Also here is the relevant dmesg when connected via 2.4ghz dongle (after setting the relevant hid quirk in kernel parameters) which fixes my issue with the 2.4ghz dongle 

      [110244.697956] usb 1-4: new full-speed USB device number 46 using xhci_hcd
[110244.839821] usb 1-4: New USB device found, idVendor=2516, idProduct=01b7, bcdDevice= 1.55
[110244.839835] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[110244.839842] usb 1-4: Product: Cooler Master Mice Dongle
[110244.839846] usb 1-4: Manufacturer: COOLER MASTER
[110244.846901] input: COOLER MASTER Cooler Master Mice Dongle as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/0003:2516:01B7.0031/input/input73
[110244.847476] hid-generic 0003:2516:01B7.0031: input,hidraw0: USB HID v1.11 Keyboard [COOLER MASTER Cooler Master Mice Dongle] on usb-0000:00:14.0-4/input0
[110244.849271] input: COOLER MASTER Cooler Master Mice Dongle as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:2516:01B7.0032/input/input74
[110244.849707] hid-generic 0003:2516:01B7.0032: input,hidraw1: USB HID v1.11 Mouse [COOLER MASTER Cooler Master Mice Dongle] on usb-0000:00:14.0-4/input1
[110244.851595] input: COOLER MASTER Cooler Master Mice Dongle Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.2/0003:2516:01B7.0033/input/input75
[110244.851810] input: COOLER MASTER Cooler Master Mice Dongle System Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.2/0003:2516:01B7.0033/input/input76
[110244.852045] hid-generic 0003:2516:01B7.0033: input,hidraw2: USB HID v1.11 Device [COOLER MASTER Cooler Master Mice Dongle] on usb-0000:00:14.0-4/input2
[110244.853729] hid-generic 0003:2516:01B7.0034: hiddev96,hidraw3: USB HID v1.11 Device [COOLER MASTER Cooler Master Mice Dongle] on usb-0000:00:14.0-4/input3
[110244.854786] hid-generic 0003:2516:01B7.0035: hiddev97,hidraw4: USB HID v1.11 Device [COOLER MASTER Cooler Master Mice Dongle] on usb-0000:00:14.0-4/input
  3. I haven't encountered any issues related to ttys since implementing the poll_always quirk. However, I hadn't tested this prior to utilizing the kernel parameter
sriemer commented 2 weeks ago
  1. I haven't encountered any issues related to ttys since implementing the poll_always quirk. However, I hadn't tested this prior to utilizing the kernel parameter

@Clutchnp Thanks so much for the additional information. :smiley: So you want me to create the kernel patch for USB ID 2516:01B7 only and send it to upstream/mainline Linux kernel?

Clutchnp commented 2 weeks ago

Sure that would be great 😃