Store Input/Output/Feature reports sizes for all platforms #731

New issue

Open

opened 2025-03-28 05:39:27 -05:00 by Youw · 3 comments

Youw commented

2025-03-28 05:39:27 -05:00

(Migrated from github.com)

I think it would generally make sense to store these 3 values in the device structure. On Windows we would have to use the values InputReportByteLength, OutputReportByteLength and FeatureReportByteLength from https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps . On all other backends we could use your parser to determine them - and with the testcase you proved that they are the same as on Windows.
In this way, we were able to programmatically determine the required buffer sizes for read/write operations on all platforms.

Originally posted by @JoergAtGithub in https://github.com/libusb/hidapi/issues/728#issuecomment-2759364768

Need to consider if this is required.

I think it would generally make sense to store these 3 values in the device structure. On Windows we would have to use the values `InputReportByteLength`, `OutputReportByteLength` and `FeatureReportByteLength` from https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps . On all other backends we could use your parser to determine them - and with the testcase you proved that they are the same as on Windows. In this way, we were able to programmatically determine the required buffer sizes for read/write operations on all platforms. _Originally posted by @JoergAtGithub in https://github.com/libusb/hidapi/issues/728#issuecomment-2759364768_ --- Need to consider if this is required.

Youw commented

2025-03-28 05:41:46 -05:00

(Migrated from github.com)

The thing is - yes, we can easily do so, but I don't remember any issues for any other backend except for Windows and Libusb where that is nesessary, i.e. other backends seem to handle report size gracefully already. (Unless those are not, and we just didn't get any complains about it yet.

👍 1

JoergAtGithub commented

2025-04-06 04:02:16 -05:00

(Migrated from github.com)

The solution would be, to determine the maximum report sizes of a device:

Using InputReportByteLength, OutputReportByteLength and FeatureReportByteLength from _HIDP_CAPS on Windows
Using the code from https://github.com/libusb/hidapi/pull/728#issuecomment-2759343386 on all other backends

If we store these 3 values in the device structure, a user could use these to dynamically allocate the buffer memory in code, that runs on every platform.

In a cross-platform application you currently can only determine the needed buffer sizes by operating system APIs. The reconstructed report descriptor on Windows can't be used here, as one of it's limitations is that we can not reconstruct the const padding bytes at the end of the report. On other platforms this can be determined from the report descriptor, as a real report descriptor contains these padding bytes. The solution would be, to determine the maximum report sizes of a device: - Using InputReportByteLength, OutputReportByteLength and FeatureReportByteLength from _HIDP_CAPS on Windows - Using the code from https://github.com/libusb/hidapi/pull/728#issuecomment-2759343386 on all other backends If we store these 3 values in the device structure, a user could use these to dynamically allocate the buffer memory in code, that runs on every platform.

Youw commented

2025-04-07 05:19:03 -05:00

(Migrated from github.com)