Added support for Get Input Report to linux, mac, windows and libusb.

[DanielVanNoord]

This was tested for all operating systems and each worked identically.

[Youw]

Windows implementation better be same as for hid_send_feature_report, to return actual length
(tested in my projects)

mac implementation sends report ID as part of data, as it was in hid_get_feature_report before #3

hidraw implementation does not respect length parameter, which may lead to memory corruption

libusb implementation seems fine to me

---

Thanks!
I was going to have it implemented for some while, this is a good start.

Some notes:

1. This is a major change (new API), we should update version too
2. Along with new version, I think it makes sense add a way to determine library version in compile/run-time.

[DanielVanNoord]

Windows implementation better be same as for hid_send_feature_report, to return actual length
(tested in my projects)
I converted it over to use this method.

mac implementation sends report ID as part of data, as it was in hid_get_feature_report before #3
See my open issue /issues/60, this works (for me) the other way does not. It is possible that my device is out of spec. But it seems really odd that all the other platforms work and mac, when implemented to spec, does not.

hidraw implementation does not respect length parameter, which may lead to memory corruption
Not sure how to fix this one. The linux api that I am using does not appear to have an option for length.

[Youw]

Not sure how to fix this one. The linux api that I am using does not appear to have an option for length.

pass pointer to stack-allocated data that is guaranteed to be large enough for the API, and then copy up to length bytes of that data to data

[Youw]

regarding mac and #60 - lets wait for comments of other maintainers/users

[Youw]

something doesn't adds up in hidraw implementation: if I understand how ioctl works, as per HIDIOCGREPORT definition, its argument can only be struct hiddev_report_info, not some user data

I'll spend more time investigating it a bit later

[DanielVanNoord]

It is possible, I wrote (and studied) the windows, mac and libusb implementations. Another developer that I worked with wrote the Linux one (I saw your issue at signal11/hidapi and am trying to up-stream now). I simply verified that it worked with both test boards that I have.

[Qbicz]

Looks good to me, with a few minor comments.

[DavidCNelson]

regarding mac and #60 - lets wait for comments of other maintainers/users

I am working on a new device with HID and also on the host side. This pull request is rather timely for me as the day it was created was the same day I was getting ready to implement the same functionality.
The issue seems to be the question if there is a report ID at the beginning of the data transfer. The HID Spec v1.11 in section 5.6 describes that if the HID device defines report IDs in the descriptor, then the report ID must be sent as the first byte of all data transfers. If the device does not define report IDs(appears as report ID == 0), then the non-existent report id is not included in the data transfer.
Consider the code in set_report in mac/hid.c at lines 774-785. If the report id is 0, it does not send the report ID as part of the data. If the report ID is non-zero, then the whole buffer is sent. A similar thing needs to happen for hid_get_feature_report and hid_get_input_report. If the report ID is 0, then the received data will not have a report ID, so the data should be read into the buffer starting with the second byte of the buffer. If the report ID is non-zero, the data received should start with the report ID, so you can fill the buffer starting with the first byte.
Depending on the device one is using, #3 fixes an issue or, as #60 points out, it is a regression.

[Youw]

HID Spec v1.11 in section 5.6 also specifies how to know if a device is using numbered reports:

A Report ID item tag assigns a 1-byte identification prefix to each report transfer. If no Report ID item tags are present in the Report descriptor, it can be assumed that only one Input, Output, and Feature report structure exists and together they represent all of the device’s data.

@DanielVanNoord, @DavidCNelson can you confirm, that your devices defines corresponding Report IDs tags in the Report descriptor?

[DavidCNelson]

HID Spec v1.11 in section 5.6 also specifies how to know if a device is using numbered reports:

A Report ID item tag assigns a 1-byte identification prefix to each report transfer. If no Report ID item tags are present in the Report descriptor, it can be assumed that only one Input, Output, and Feature report structure exists and together they represent all of the device’s data.

@DanielVanNoord, @DavidCNelson can you confirm, that your devices defines corresponding Report IDs tags in the Report descriptor?

Yes, the device I'm working with does define report IDs in the descriptor, and so we do use report IDs for all transfers.

[DanielVanNoord]

Same here, the device I am working on uses report IDs in the descriptors for all transfers.

[Youw]

@DanielVanNoord please resolve merge conflict, and:

• update mac implementation as per macOS: send report id conditionally for hid_get_feature_report #70
• update windows\ddk_build\hidapi.def

[DanielVanNoord]

@Youw Should be taken care of now