HID Report Parser for HIDAPI

[mcuee]

Reference:

• HID reports of more than 64 bytes and libusb backend #274
• Use upstream hidapi 0.14.0 with hid_get_report_descriptor on all platforms supercollider/hidapi#18

The main hidapi tree will maintain the exting licenses (triple licenses). The exising HID Report Parser in the SuperCollider fork is using GPL so it can not be directly used.

One potential way is to have a branch or a new repo to host that integration if some one is interested and if they are okay with GPL license.

[JoergAtGithub]

The parsing code needed to fix #274 will be about 50 lines of code. This does not require a full blown ReportDescriptor parser.
Technically the hidapi contains already a report descriptor parser to determine Usage and UsageTable in the libusb backend:

hidapi/libusb/hid.c

Line 270 in a88805e

while (i < size) {

the code to determine the report size per ReportId could be integrated here, than we would need to add even less lines of code.

[mcuee]

@JoergAtGithub

So you are basically saying it is not that difficult to fix #274 and we do not need to use the GPL codes at all. Glad to hear that.

[mcuee]

BTW, the old libhid has a GPL licensed hid parser as well.
https://alioth-archive.debian.org/releases/libhid/libhid/

I even keep a Windows port here.
https://github.com/mcuee/libhid-win

hidrd is also GPL licensed.
https://github.com/DIGImend/hidrd

[mcuee]

This Python HID parser has MIT license.
https://github.com/usb-tools/python-hid-parser

This C based parser does not seem to be so complete, with MIT license as well.
https://github.com/listff/hidparser

This Python based HID/PID Report Descriptor parser is more complete, not so sure about the license.
https://github.com/beantowel/HID-descriptor-tool

[Youw]

My oppinion of having the HID Descriptor parser inside HIDAPI is the same: not much point having such, definitely not as a part of this repo (even in a branch).

There're multiple existing implementation (thank you @mcuee for examples above), and if someone needs any of those - there are multiple options to choose from.

And in the context of #274 - I agree, that minimally extending the existing parser would make the best sense, as @JoergAtGithub described above.

[mcuee]

In this case I will close this issue.