Re: Report ID problem with HID-RAW interface usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi  ,

ok i explain my requirements again .


(1)

the hid device  i am  dealing with does not tell in its payload
protocol specifications
how many input and output reports it will support and what will be the
their respective size . the only thing it tells is payload data will
be in the format
<Report ID> <Payload > .

 >If you know what type of device you are talking to, then you shouldn't
> really need to parse the descriptor in software, because you'll know what
> the device supports, right?
>

No , this information is not available to me in advance .
the application should parse the report descriptor currently
and identify the no of input and output reports currently available
along with their sizes .

infact in my view , it does make sense to get <Report ID> <Report Len >
from report descriptor only , as a device protocol specification may change
for its  future releases . and no of reports may increase .
so its better to get this information from report descriptor only sent
by the device .


(2)

now lets consider the case for sending report to device .

different output reports have different sizes .

so depending upon application payload length ,

i have to select which < output report ID > should be used .

so hid_write should be

buff[0] =  < Output Report ID having Report Len >= application payload >
buff[1....n] = <payload data > .

since i need to know dynamically which output report id should be used
i stressed the need for ioctl which can fetch  the basic information
 <Report ID ><Report Len> parsed from report descriptor send by the device .

i agree hidraw interface sends / receives raw events and
this functionalty indeed is required by my application ,
but still to send report , i need to choose report id depending
upon application payload size .
Also report id and report length information supported is not
described in device protocol specs .

i think hidraw interface should provide support for
<report id > <report len > information as application needs to
dynamically provides information
to buff[0] = <Report ID> ( we cannot hardcode this value )

(3)

now lets consider the case for hid device read .

the syntax is read( fd , buff , count );

what i want is

buff[0]  = <Input Report ID>
buff[1...n] = <Report Payload >

Yes i agree the < Report type > information is not required .

as i explained previously one application payload can be split across
multiple reports using same <Report Id >

so if Report ID information also comes in buff[0]
it becomes easy to identify one application payload spilt across multiple
reports using same <Report ID>.


(4)

Regarding libusb / libhid usage ,
the usb device i am using is a composite device
having hid and audio interfaces .

is it possible to claim audio interface from kernel space
and hid interface from user space ?

Thanx & Regards
Amit Nagal
















On Wed, Jun 30, 2010 at 5:54 AM, Alan Ott <alan@xxxxxxxxxxx> wrote:
> On 06/30/2010 07:14 AM, Amit Nagal wrote:
>>
>> sorry my mistake :
>>
>> what i wanted to ask was ioctl with which application can get
>> input / output / feature<REPORT ID>  and<  REPORT LEN>  .
>>
>> Thanx&  Regards
>> Amit Nagal
>
> Amit,
>
> There is a new ioctl() staged for the new merge window which will get and
> set feature reports. It is used like this:
>
>        /* Set Feature */
>        buf[0] = 0x9; /* Report Number */
>        buf[1] = 0xff; /* data */
>        buf[2] = 0xff;
>        buf[3] = 0xff;
>        res = ioctl(fd, HIDIOCSFEATURE(4), buf);
>
> Is that what you're asking for, or are you asking for something which will
> tell you which reports are _available_ on the device, and what their lengths
> are? There is currently no way to report which reports are _available_. As
> Jiri said, HIDRAW does not do any parsing of the report descriptor. All data
> is passed "raw" from the user application to the device.
>
> If you know what type of device you are talking to, then you shouldn't
> really need to parse the descriptor in software, because you'll know what
> the device supports, right?
>
> Alan.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux