Repository navigation
Store Input/Output/Feature reports sizes for all platforms #731
Description
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 #728 (comment)
Need to consider if this is required.
Activity
Youw commentedon Mar 28, 2025
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.
JoergAtGithub commentedon Apr 6, 2025
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:
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 commentedon Apr 7, 2025
All true. And that's what I implied when I mean that this can be easily done.
The question here - is it really needed?