On Fri, 01 Oct 2010 20:30:36 -0400
Alan Ott [off-list ref] wrote:

quoted

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index df80532..83e1b48 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c

@@ -875,6 +875,9 @@ static int usbhid_output_raw_report(struct hid_device *hid, __u8 *buf, size_t co
                         ((report_type + 1)<<  8) | report_id,
                         interface->desc.bInterfaceNumber, buf, count,
                         USB_CTRL_SET_TIMEOUT);
+               /* restore report ID into the buffer, some non conformant usb
+                * device could have mangled it */
+               buf[0] = report_id;
                 /* count also the report id, if this was a numbered report. */
                 if (ret>  0&&  skipped_report_id)
                         ret++;

But I haven't even taken a look at the HID spec about this, so take it
just for the sake of discussion. Anyone could run some tests with other
devices?
   

I actually don't like it (I did see your later email about how you 
really meant for it to be in usbhid_get_raw_report(), so consider this 
my response to that). I don't like it because hidraw is supposed to be 
raw. If the device sends back bogus stuff, then bogus stuff should be 
passed back to userspace. Likewise, if the host tries to send bogus 
stuff to the device, then it should be able to (or be able to try). The 
problem with enforcing rules here is determining which rules to enforce. 
For example, with hiddev, you can't get or set reports that aren't in 
the HID descriptor. That keeps you from being able to get report 0xf5 
which is required to use the sixaxis device. I think this goes against 
the idea of "raw," and could even mislead the user to think that a 
device is functioning properly (or has been implemented properly) when 
it is not.

Ok, I see your point and you convinced me, let it be "raw" then.
If you are going through another iteration of the documentation patch
maybe you can mention that buf[0] in the returned descriptor can be
pretty much everything when dealing with deviated devices.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?