On Wed, May 18, 2022 at 10:04:14PM +0000, Matt Silva wrote:
Hi, Greg. Thanks for the response, I really appreciate it! Awesome to get a reply from the man himself.
Probably wasn't the best from me to refer to the Windows software as a driver. As far as I can tell it is just a userspace application using the Windows interface to communicate, as you described below.
From my understanding, the device intends to operate as a HID device (unless your comment below about all devices claiming to be HID when they're not on Windows applies here), it even provides a HID descriptor with usages to Windows. It's also my understanding that for certain devices with "quirks" that don't operate normally, the Linux kernel has quirks that allow these edge case devices to operate as intended.
But this really is not a HID device, right? What is the HID descriptor that it prints out? Can you use the 'usbhid-dump' program that is part of the usbutils package to show the report descriptors?
So while your feedback about using libusb for OpenRGB in userspace definitely doable, I was curious if this device would benifit from having support for its quirk added to the kernel so that it can be exposed in userspace as it intends, rather than just solving my specific problem for OpenRGB. As far as I can tell, the interface never communicated to directly through its single OUT endpoint. The communication is through the control endpoint via a SET REPORT request. I did some reading and you are correct, HID class interfaces require a interrupt in endpoint. But like I said, the fact that it only communicates via the control endpoint made me think that maybe this requirement may not be necessary for the interface to function as intended.
If this is all going through a "fake" SET REPORT command, in a vendor-specific way, I would just recommend doing it all from userspace using libusb like OpenRGB does for other devices. No need to mess with the kernel at all for a fake HID device like this. good luck! greg k-h