hid_get_input_report returns one byte more than hid_read, also how to deal with hid_get_feature_report

[JoergAtGithub]

hid_get_input_report returns one byte more than hid_read

If I read the same report using hid_get_input_report and than with hid_read, the return value is I get different number of byes read as return value.

This is for the case of a single input report (I reported a maybe related issue about for the case of two input reports here #210 )

This occurs on Windows 7 with HIDAPI 0.10.0

[JoergAtGithub]

The code of hid_get_input_report contains:
/* bytes_returned does not include the first byte which contains the
report ID. The data buffer actually contains one more byte than
bytes_returned. */
bytes_returned++;

I compared this with the implementation in Google Chrome (WebHID backend), and they read the data using the same API, but do not increment the byte count:
https://chromium.googlesource.com/chromium/src/+/cebcd836b83e1d48db1000b2a5878aa90bc7e88b/services/device/hid/hid_connection_win.cc

[jonasmalacofilho]

(Arriving here from a reference in another issue...)

That is the documented behavior of hid_get_input_report when report IDs are not used, which could be the case here, since there is a single report.

hidapi/hidapi/hidapi.h

Lines 370 to 376 in 6a01f3b

	/** @brief Get a input report from a HID device.
	Set the first byte of @p data[] to the Report ID of the
	report to be read. Make sure to allow space for this
	extra byte in @p data[]. Upon return, the first byte will
	still contain the Report ID, and the report data will
	start in data[1].

hid_read, indeed, follows different semantics.

hidapi/hidapi/hidapi.h

Lines 271 to 275 in 6a01f3b

	/** @brief Read an Input report from a HID device.
	Input reports are returned
	to the host through the INTERRUPT IN endpoint. The first byte will
	contain the Report number if the device uses numbered reports.

---

Addendum

That is at least a reasonable interpretation of the documentation for hid_get_input_report. However, the same text appears in hid_get_feature_report which, in turn, seems to have conflicting implementations:

• the libusb implementation appears to follow the interpretation above;
• but the hidraw implementation simply wraps HIDIOCGFEATURE, which is documented to have a different behavior: "For devices which do not use numbered reports, the report data will begin at the first byte of the returned buffer."

[mcuee]

http://janaxelson.com/hidpage.htm
Jan Axelson's page may be of some interests. Including FW codes to be used for test device.

[mcuee]

Historical info about feature report.
https://marc.info/?l=libusb-devel&m=128378733122118&w=2

https://github.com/libusb/hidapi/blob/master/windows/hid.c#L56
#define IOCTL_HID_GET_FEATURE                         HID_OUT_CTL_CODE(100)
#define IOCTL_HID_GET_INPUT_REPORT              HID_OUT_CTL_CODE(104)

---

List: libusb-devel
Subject: Re: [Libusb-devel] Returned HID feature report size on windows
From: Alan Ott <alan () signal11 ! us>
Date: 2010-09-06 15:35:11
Message-ID: 4C850A2F.5090509 () signal11 ! us
[Download RAW message or body]

On 09/04/2010 10:18 PM, Xiaofan Chen wrote:

ReadFile() is generic and should be able to be used for
input/output/feature reports.

...

You may want to get some hints from Alan Ott's code. Now
he is using ReadFile for Feature Report.
http://github.com/signal11/hidapi/blob/master/windows/hid.cpp

ReadFile() will only give input reports which came back on the
Interrupt-IN endpoint. To get a feature report and also its length, you
have to use the DeviceIoControl() call instead of HidD_GetFeature(). The
problem is, the definitions of the IOCTLs are only in the DDK, and
they're not even in the same place as the hid.dll headers. Further,
there are two sets of IOCTLs, one for kernel-space, and one for
user-space, which do many of the same things.

I was eventually able to figure it out, and if you look here:
http://github.com/signal11/hidapi/blob/master/windows/hid.cpp

at the hid_get_feature_report() function, you'll see what works.

... skipped ...

[mcuee]

Ref from Microsoft, which is said not to be so clear.
https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/obtaining-hid-reports

[mcuee]

Please check my test result also.
#232

Test FW and libusb code
https://github.com/mcuee/picusb/tree/master/lvr_genhid_mod

hidapitester results: it seems input report is correct but feature report has an issue as it reads back 4 bytes.

$ ./hidapitester.exe --vidpid 0925:7001 -l 3 --open --send-output 2,0x21,0x22 --read-input 1
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 02 21 22
Reading 3-byte input report 0, 250 msec timeout...read 3 bytes:
 01 21 22
Closing device

$ ./hidapitester.exe --vidpid 0925:7001 -l 3 --open --send-feature 3,0x31,0x32 --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 3-byte feature report...wrote 3 bytes:
 03 31 32
Reading 3-byte feature report, report_id 4...read 4 bytes:
 04 31 32
Closing device

[mcuee]

I just purposefully send one more byte and here is the test result. No issues with the input report and feature report.

$ ./hidapitester.exe --vidpid 0925:7001 -l 4 --open --send-feature 3,0x31,0x32,0x33 --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 4-byte feature report...wrote 4 bytes:
 03 31 32 33
Reading 4-byte feature report, report_id 4...read 4 bytes:
 04 31 32 00
Closing device

$ ./hidapitester.exe --vidpid 0925:7001 -l 4 --open --send-output 2,0x21,0x22,0x23 --read-input 1
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 4-bytes...wrote 3 bytes:
 02 21 22 23
Reading 4-byte input report 0, 250 msec timeout...read 3 bytes:
 01 21 22 00
Closing device

[Youw]

If I understand your results correctly, hid_get_input_report actually works fine, but hid_get_feature_report doesn't.
This makes #232 invalid.
UPD: comments below.

---

@JoergAtGithub something I've failed to ask you earlier:
Does you device uses numbered reports?