Supporting a USB HID device interface that is missing a interrupt input endpoint

Matt Silva msilva-dev at protonmail.com
Mon May 16 19:40:09 EDT 2022


Hi, first time emailing here, so if there are any issues with my question, let me know and I'll fix it.

Basically, I'm working with a USB HID microphone that also supports RGB features. I'm working to reverse engineer the RGB features provided by a proprietary Windows driver and add support to OpenRGB.

The issue is that the interface that handles the RGB packets only has an OUT interrupt endpoint (rather than an IN interrupt) and as such doesn't get picked up by the usbhid driver (and therefore can't be picked up by the HIDAPI library that OpenRGB uses). However, on Windows this interface is detected as a HID device. I've narrowed down where this happens to "drivers/hid/usbhid/hid-core.c:1350", and making some testing changes there to check when the device idVendor, idProd, and interface number match and then only check for endpoint being interrupt rather than input interrupt, I can get the kernel to properly associate the interface with the usbhid driver.

My main question is regarding how this change should be implemented.

Should it be done as some sort of hid quirk in kernel? Or is this something that should be done in userspace where the device is forcibly added as a usbhid device maybe through a udev rule or something?

Also, if it is some sort of kernel adjustment, is the area I mentioned above the correct place to put the check? I'm still doing some searching, but I'm worried about some other portion of the usbhid driver that assumes the interface endpoint is an IN and could cause some sort of clash.

Looking for some guidance on this. Still new to kernel dev and the usb+hid systems.

I appreciate the help :)



More information about the Kernelnewbies mailing list