Hi , Also i want to bring to notice the following facts regarding hidraw interface : 1) it seems no documentation is available in the linux kernel regarding hidraw interface usage . it should be available like the hiddev interface file hiddev.txt . (though on browising over net i do find hidraw.txt , but it shud be there in linux kernel documentation ) . 2) no ioctl is available to fetch input / output / feature report id and size . userspace application has to parse report descriptor on its own and fetch report id and size . if some ioctl is there to fetch report id and size . it is much more convinient for the application to use hidraw interface . thanx and regards Amit Nagal On Wed, Jun 30, 2010 at 12:39 AM, Amit Nagal <helloin.amit@xxxxxxxxx> wrote: > Hi , > > > Thanx for the reply . > > The below discussions clears the ambiguity regarding <report id > usage . > > I hope some patch regarding the same bug fix will be there for hidraw > interface . > > Thanx & regards > Amit Nagal > > > > On Tue, Jun 29, 2010 at 4:32 PM, Xiaofan Chen <xiaofanc@xxxxxxxxx> wrote: >> On Wed, Jun 30, 2010 at 12:30 AM, Alan Ott <alan@xxxxxxxxxxx> wrote: >> >>> I thought I'd be able to just go check the HID specification and be able to >>> say that the report number is not sent as part of the payload for Set_Report >>> devices, since it would be redundant because the Report ID is sent over in >>> the wValue field. >>> >>> Unfortunately, I was not able to see that clearly laid out in the HID >>> specification in the section on Set_Report. I did however find language >>> saying "if a Report ID tag was used in the Report descriptor, all reports >>> include a single byte ID prefix," in section 8.1, Report Types. >>> >>> I did some tests with the Windows implementation, and indeed, when numbered >>> reports are used in the HID descriptor, the Windows implementation will send >>> the report ID as the first byte of the payload.>> >>> Based on the language in the HID spec, and the behavior of Windows, I >>> believe the buf+1, count-1 to be a bug. >>> >> >> Yes I think it is a bug. >> >> And the HID specification states: >> "If a Report ID tag was used in the Report descriptor, all reports >> include a single byte ID prefix. If the Report ID tag was not used, all >> values are returned in a single report and a prefix ID is not included >> in that report." >> >> My understanding is like the following and testing confirms it. >> 1) when HID device has explicit report IDs, then the report IDs will >> be transmitted on the bus. >> 2) when the HID device does not use report ID at all (implicit report ID 0), >> then this report ID 0 is not transmitted on the bus >> >> Reference: >> http://www.microchip.com/forums/tm.aspx?m=494711 >> http://libusb.6.n5.nabble.com/Missing-first-byte-when-reading-HID-Feature-Reports-with-ID-td9460.html >> (we spent quite some efforts to get the libusb-1.0 Windows native >> HID backend to deal with report ID correctly). >> >> -- >> Xiaofan http://sourceforge.net/projects/libusb-win32/ >> > -- 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
