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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
