Need API to get the HID Report Descriptor or a similar data structure #249
Comments
|
Potentially helpful links: https://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/ |
|
Actually, it somewhat comes for free as the basic usage page and usage are extracted from the report descriptor which is read here: Line 644 in 0ea5e95 In my eyes it'd make sense to directly store this descriptor either
That said, it might be nice or meaningful to somehow incorporate this quite nice descriptor to string parser based on which I'm momentarily trying to make a generic parser to help extract meaningful values from given reports without having to know the report layout beforehand (primarily trying to make it work with my use cases, but for simple devices should be fine). |
|
Thanks for that info @tschiemer. I have not looked into what it would take to implement this. If you have a branch of hidapi you are working on, please open a pull request for this upstream repository and I'd be happy to test it with my Native Instruments Traktor Kontrol S4 Mk3. |
|
Ok, can see to it, but might take a moment |
While this indeed already available and easy to get for libusb and hidraw backends, one of the first things about HIDAPI is being cross-platform. I agree that this would be very useful, but Windows backend doesn't have an API to get a descriptor at all. |
|
There's also the approach to use the generic WinUSB driver (comes with Win7 or newer) instead of Windows High-Level-HID-API: #61 (comment) |
Yeah, and someone actually needs to make a driver for each specific device. And the problem not even with making a driver - a template inf file can be generated. But signing a driver properly - that requires some effort. And you'd need to compile a libusb backend on Windows, which isn't compilable of-the-box yet. |
|
Ok, that doesn't sounds like what we're looking for. |
|
I think it could be a good idea to start with libusb or hidraw to figure out what the API should be then implement it for other backends. |
|
@Be-ing so not quite a hidapi branch, but as a proof of concept I implemented this puredata external to parse input reports based on the report descriptor, works for me on macos and a rpi4/linux with a joystick and mouse (see releases for binaries). It's a bit of a mess as it uses libusb to find devices according to search criteria (more than hidapi provides out of the box, but meaningful in my opinion and based on hidapi-libusb internals) and reads/parses the report descriptor but relies on hidapi to actually receive input reports (and thus on linux the device listing is set to detach devices as in the hidapi driver..) - should have had a deeper look at hidapi's (or hidraw) interface before.. At the moment only the raw values as given in the input report are extracted without making use of any of the logical/physical min/max, unit, exponential etc values but adding that shouldn't be too big of a deal.. Maybe this is helpful in some form |
I implemented such a reconstructor in C and will start a Pull Request for HIDAPI soon. Stay tuned! |
|
I started PR #262 with a C implementation of the Windows Report-Descriptor code. |
|
I think libusb HID backend has already the codes to partially reconstruct the descriptors. Some from the USB HUB driver, some from the USB HID driver. But that may not be suitable for HIDAPI as it is also for bluetooth devices. https://github.com/libusb/libusb/blob/master/libusb/os/windows_winusb.c#L3728
|
|
FYI I have just tested win-hid-dump. It seems I got some problems with it. |
|
But HIDSharp seems to work (not checking the contents). I have a long list of HID device in the system (Windows 10, Dell Laptop with a docking station). Edit to add: it is not stable for my system and the output does not seem to be correct, at least for my Microchip PICKit 2). click to expand |
2 tasks
|
mac-hid-dump output seems to be a bit too simple. Edit to add: but external tools can parse the output. Raw HID reports (part of Logitech USB Receiver): Parsed output from the above website. |
I tested your new code, on my Windows 7 system. unfortunateley it always fails with: I would be glad if your approach would work, because gather the real Report Descriptor would be better than any reconstruction. |
|
@DJm00n I tried RawInputDemo under Windows 10 using VS2019, no problem running it but the RawInputDemo.exe does not seem to do anything. How do I use it? |
|
@JoergAtGithub #262 seems to running fine at my Dell Windows 10 laptop with a docking edition and quite some HID devices. The only problem is that I do not know the original HID report descriptor of the devices other than the device I have access to the FW (say Microchip based Simple HID Demo, PICkit 2, Lakeview Research HID demo) and they are on the simpler side. |
Further test shows that HIDSharp is not so stable for my system, sometime it hangs. Pull request #262 seems to be pretty stable and product consistent results (but I need to check whether it is correct or not). |
|
@mcuee sorry. I forgot to mention - it outputs info to debug console window in msvs. |
This is what I got in the VS2019 output window. Where can I see the debug console? Sorry but I seldom use VS. |
|
I found that pull request #262 is not correct for Microchip PICKit 2 and then I run HIDSharp again and it is also not correct. Original HID report descriptor Dumped by pull request #262 https://eleccelerator.com/usbdescreqparser/ output. As a comparison, this is what I get from HIDSharp which is also not correct. |
|
The HID Report Descriptors that HIDSharp (and It should be semantically (to the OS) the same, however. If it's not, it usually means the descriptor sent by the device is wrong in some subtle way. For vendor usages, this doesn't much matter, as then all that really matters is REPORT_ID, REPORT_COUNT, and REPORT_SIZE |
I understand, but in this case, it is quite a bit OFF. It is totally different from what the device does. REPORT_COUNT and REPORT_SIZE are totally wrong. #262 actually looks better in this case. |
|
@todbot Maybe this device is indeed strange, it has two USB configurations but that should not matter as Windows will ignore the second configuration. Full USB Descriptor C source code for reference. click to expand |
|
@Youw So basically the Logitech device does not show proper path. mac_hid_dump (https://github.com/todbot/mac-hid-dump/blob/main/mac-hid-dump.c) does not use the path so it does not have such issue. |
|
@Youw Okay, I figured out the issue, the issue is not with your codes, but rather #236. I have two external hubs (USB 3.0 --> USB 2.0) so the path is too long. My External Hubs are more complicated hubs (nested hub). Once I move the Logitech receiver to the root hub, it will mostly succeed. If I move it to the Port 7 of the first external USB 3.0 hub , it is still not working though. If I moved it to the Port 1 of the external USB hub, it will mostly succeed. If I move it to the root hub, almost everything will succeed, except one. Full output once I move the receiver to the root hub. click to expand |
GJ finding that out. So it works from the ROOT hub with the original implementation (with |
Yes that is correct, except one device as mentioned above. I tend to think it may still be due to #236. |
|
#322 has been merged. So I apply the two patches from the macOS get-descriptor branch and here is the result. The way I apply the patch may not be so correct but the patching is successful. Only one output is a bit strange. |
|
@Youw The issue goes away once I run with sudo. Not so sure why. |
Not sure either. |
Indeed that makes the difference. With the change, no need to use sudo. |
|
That means that there is another application/daemon running in the background that has that device opened. |
|
Just the latest test result from the get-descriptor branch under Windows. Click for the run log |
|
Can I somehow help to get the |
|
Get me fired from my current/main job :D |
Actually you can: Right now the struct rd_buffer {
unsigned char buf[HID_API_MAX_REPORT_DESCRIPTOR_SIZE];
size_t size;
};in this case we still going to have convenient My second consern is the implementation of So I think we will have it mostly as is (except my consern above), but run it thru some static analyzers (we have setup project for coverity, and run unit-tests we have with ASAN enabled (maybe even have it enabled for our CI). If no issues found (or after all issues fixed) - that will be the last item in my checklist for that branch. |
|
I will look, how I can adapt the proposed rd_buffer approach! To have static code checkers in CI, makes sense to me. I wonder, how it will handle the preparsed_data itself, where the memory allocation happens in WIN32 API code and only a pointer to the struct of variable size is returned. Everything else is under our control, and therefore, should be fixable. |
1 task
|
Just another test results. run log for hidtest |
|
One more test results with latest commit. run log for hidtest |
|
Comparison with libusbK kList utility for the Mi Wireless Mouse USB Receiver, by attaching libusb0.sys filter to the device. |
|
Great that this PR has finally been merged. |
This was referenced May 2, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We need a function to read the HID Report Descriptor or an equal data structure with information about the fields in the different HID reports.
Background:
For the cross platform Mixxx DJ software we need a solution, to allow the end user to map HID controller buttons, faders, knobs, RGB LEDs, etc. These are different on any DJ controller. Therefore this mapping it must be customizeable by end users.
As input we need information about the field, e.g.: a 12 bit field at position n of Input report with ID0x02 with a logical minimum of -2048 and a maximum of +2047.
The text was updated successfully, but these errors were encountered: