hidapi
hidapi copied to clipboard
Store Input/Output/Feature reports sizes for all platforms
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.
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.
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.
All true. And that's what I implied when I mean that this can be easily done.
The question here - is it really needed?