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: Tue, 17 May 2022 08:18:50 +0200 [thread overview]
Message-ID: <YoM+SiZrPAIIGE/0@kroah.com> (raw)
In-Reply-To: <1sT3lu7QxRdv6jrZycSEE8VsfPtAXiJNL5BBDBp-cMiTG3DbEau-NDI_mo8leikQo5u6KBwPS-mb_6sz0aja8idAVM5hMwg2oQ6dRzjJrXo=@protonmail.com>
On Mon, May 16, 2022 at 11:40:09PM +0000, Matt Silva wrote:
> 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.
If this is a custom windows kernel driver, perhaps you don't need to
talk HID to the device at all?
Or is this just a device that is using the userspace Windows HID
interface to talk to the device directly without any kernel code needed
(that used to be the only way userspace programs could talk to USB
devices on Windows for vendor-specific devices, so they all claim to be
HID when they really are not.)
> 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.
A USB HID device has to have an interrupt IN endpoint to be HID
compliant from what I remember in the specification, so the kernel is
correct here. But you should double check this with the specification
to be sure (they are free to download from usb.org).
> My main question is regarding how this change should be implemented.
Why not just talk directly to the device using libusb from userspace?
I don't know how openrgb works, but odds are there are other devices
that do not register as HID devices that it supports?
Hope this helps,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2022-05-17 6:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 23:40 Supporting a USB HID device interface that is missing a interrupt input endpoint Matt Silva
2022-05-17 6:18 ` Greg KH [this message]
2022-05-18 22:04 ` Matt Silva
2022-05-19 7:38 ` Greg KH
2022-05-26 20:06 ` Matt Silva
2022-05-27 6:13 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YoM+SiZrPAIIGE/0@kroah.com \
--to=greg@kroah.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=msilva-dev@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.