Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Youw opened this issue Mar 28, 2025 · 3 comments
Open

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

Youw opened this issue Mar 28, 2025 · 3 comments
Labels
enhancement New feature or request

Comments

@Youw
Copy link
Member

Youw commented Mar 28, 2025

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.

@Youw
Copy link
Member Author

Youw commented 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
Copy link
Contributor

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
Copy link
Member Author

Youw commented 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants