GetInputReportBufferSize() call in RequestToGetInputReport() method

[Zep]

I have been working with the Generic HID CS 6.0 now for a while and have been wondering about the following.:

Is it not possible that a device can change the "numberOfInputBuffers" in different "modes" ?

I have a device that usually have 8 byte inputreports but have space for 4 reports (32 bytes all in all).
It seems to me though that when I operate it in a different mode where it only needs to send back 8 bytes, it also only HAVE those 8 bytes. So 1 report instead of 4.

So my question is if there should not be a "GetInputReportBufferSize()" call in the beginning of the "RequestToGetInputReport()" method also to make sure it is reported correct?

I am not sure about my "debugging" of the device's number of reports yet so I might be way off with this, but just a thought.

[Jan Axelson]

The buffer size in GetInputReportBufferSize and SetInputReportBufferSize is the maximum number of reports the host's HID driver will store.

For example, if set to 8, and if the device sends reports periodically but the application isn't reading them, when the 9th report arrives, the HID driver will drop the oldest report. If the application is reading the reports as fast as they arrive, the input buffer size never comes into play.

 

 

[Zep]

Yes. I am aware of what it is.

My question is if it is not possible that the device can change that number in different situations.

Like when reading data from the device it can be 32(4 x 8 bytes) but when writing to the device's configuration it can change to 8 (1 x 8 bytes) because it only needs to respond with a 8 byte ack.

[Jan Axelson]

The input buffer size that the API function sets has nothing to do with the amount of data a device sends in a report. That value/values are set by the report descriptor.

[Zep]

I know.

I am probably not expressing myself correct, but I can not see another way expressing it right now.
I still see this as an issue and I will get back when I am able to explain it.