On Fri, 01 Oct 2010 20:30:36 -0400 Alan Ott <alan@xxxxxxxxxxx> wrote: > > 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?
Attachment:
pgpalZyjwpFbD.pgp
Description: PGP signature
