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