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

From: Greg KH <greg@kroah.com>
To: Matt Silva <msilva-dev@protonmail.com>
Cc: "kernelnewbies@kernelnewbies.org" <kernelnewbies@kernelnewbies.org>
Subject: Re: Supporting a USB HID device interface that is missing a interrupt input endpoint
Date: Thu, 19 May 2022 09:38:53 +0200	[thread overview]
Message-ID: <YoX0Dd/VmkzVmmRt@kroah.com> (raw)
In-Reply-To: <vu8STBurL5SbEdlkJg0_YTRyy2c0SbglHzFbvYLW7C4N_Ui0pglwNwSS-300k7vuixyJKhNvmBaNJeo0qhJQRInsBwazfGPnV2XSMoERWeU=@protonmail.com>

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies