So let me see if I understand correctly (let me know yes or no on each):

1. You do not have documentation which tells what reports are available on
the device.

Yes . documentation tells only that data payload will come in form
<Report ID> <Payload>
No documentation is there to tell what reports are available on device .

2. The number and size of reports is listed in the HID descriptor, which you
do not want to parse in userspace. You want the kernel to do it for you
(which is a reasonable request, as modules like hiddev already do this kind
of parsing).

Yes . its better if kernel do it it . otherwise each application
utilising hidraw
interface will have to maintain its own parser to get this minimum information
regarding No of reports and their len .

if kernel provides this minimum info , hidraw offers a very convinient
interface to communicate with a hid device using standard
open/read/write/ioctl system calls.
and its very useful for applications which are interested in getting
raw events only from device
without dwelling much deeper into the complexities of hid specs .

3. You want to be able to support the future releases where the report sizes
may change.

Yes. definately it is required .

I think I'm finally getting the picture. Again, tell me yes or no on each:

0. You're using HID device with User-Defined data.

Yes . the device data is mostly in the form of <command > < response > .

1. Your device has lots of reports, which all take the same type of data.

Yes . the device has lots of inputs and output reports .
the report values are <command > < response> only .

2. Each report differs _only_ in its length, but the data is the same. For
example:
       1. If you want to send 5 bytes to the device, you use report 1, which
is 5 bytes long
       2. If you want to send 10 bytes to the device, you use report 2,
which is 10 bytes long.
       3. if you want to send 20 bytes to the device, you use report 3,
which is 20 bytes long.
       etc.

Yes. exactly . data  payload len is the defining parameter to
determine the report N to use .

4. You want to know dynamically, which report you need to use, based on the
payload length, because
4a. the only difference in your reports is the payload length.

Yes .  Report selection should  be dynamic .

Might I ask what kind of device this is that behaves this way?

it is Ipod .  i am enclosing report_descriptor and lsusb files for the same .

For a device which uses numbered reports, the input report ID is always
returned to read(). It's already doing what you're asking for.

it is ok .  read() calls returns  < report id > .

read() is going to return one report per call to read(). It's not a stream
interface. If your data is split across multiple reports, you'll need to
stitch it back together on your end.

yes . i agree .


Thanx & Regards
Amit Nagal