Re: Report ID problem with HID-RAW interface usage

[Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>]

>> 2)
>>
>> ioctl  which sets a flag so that when device sends a report , report
>> id&  report type  is prefixed
>> to output of read() .
>> i mean when application calls read , it gets input report as<report
>> id><report type><payload>
>> right now we get<payload>  only .
>>      
> Please see the commit 5a38f2c7c4dd53d5be097930902c108e362584a3. That makes
> sure that report id should be there properly. Do you still see any problem
> with this commit applied? (2.6.34 is the first kernel to have this one).
>    

That commit removes an extra byte from the beginning of reports handed 
to read(). If I understand correctly, it doesn't do what he's asking.

For devices which use numbered reports, reports which come from read() 
have the report ID at the beginning, in the form:
<report_id><payload>

For devices which do _not_ use numbered reports, only the payload is 
sent. Of course, since the device only uses a single report, a report 
number does not even make sense, and is not needed, since you know which 
report it is (as there is only one). The form is:
<payload>

It is not necessary to return the report type, because the read() 
interface will only give you INPUT reports which come over the INTERRUPT 
IN endpoint (usually EP 1 IN). FEATURE reports must come through the 
GET_FEATURE request over the CONTROL endpoint, initiated by the 
HIDIOCGFEATURE ioctl (Note that this ioctl is part of what Jiri has 
staged for the next merge window, and is not part of the current 2.6.34 
Kernel). OUTPUT reports are never sent from the device on the INTERRUPT 
IN endpoint. In short, if it comes from read(), it's always an INPUT report.

Alan.


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html