Skip to contentSkip to conversation

Bug in hidraw When a HID Device Contains Multiple Reports

PATCH In review Alan Ott 3 participants 3 messages Apr 26, 2010 – Apr 27, 2010 HID

lore
Share & tools
lore

Alan Ott

author
#0 lore raw

PATCH 1/1 Bug in hidraw When a HID Device Contains Multiple Reports

From: Alan Ott <[email protected]>

Make hidraw not stick an extra byte on the beginning of an IN transfer when a HID device contains multiple reports.

---

In drivers/hid/hid-core.c, hid_report_raw_event() does the following to pass the raw data to hidraw:

        if (hid->claimed & HID_CLAIMED_HIDRAW) {
                /* numbered reports need to be passed with the report num */
                if (report_enum->numbered)
                        hidraw_report_event(hid, data - 1, size + 1);
                else
                        hidraw_report_event(hid, data, size);
        }

The data-1 and size+1 add an extra byte to he beginning of the data which is _not_ the report number. The report number is located at data[0], not data[-1].

I followed the data all the way from its source in the urb:
1. drivers/hid/usbhid/hid-core.c passes urb->transfer_buffer to
2. hid_input_report() (drivers/hid/hid-core.c) who passes it to
3. hid_report_raw_event() (drivers/hid/hid-core.c), who passes data-1 to
4. hidraw_report_event() (drivers/hid/hidraw.c), which puts the data in
a buffer for hidraw_read() to pick up.

Nothing in the chain indicates that the data pointer which arrives in hid_report_raw_event() is offset by one.

Quoted 1 line

From a multi-report HID device, I can send 4 bytes (report number + 3

data bytes) and see a return of 5 bytes from read() (hidraw_read()) which is the data I would expect with an extra byte (0x0) stuck to the beginning of it.

I have attached a patch which seems to take care of this problem. Please let me know if I have completely misjudged the situation.

Alan.

drivers/hid/hid-core.c +2 -7
index 2e2aa75..0e4a6fb 100644
@@ -1043,13 +1043,8 @@ void hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size,
 
 	if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
 		hid->hiddev_report_event(hid, report);
-	if (hid->claimed & HID_CLAIMED_HIDRAW) {
-		/* numbered reports need to be passed with the report num */
-		if (report_enum->numbered)
-			hidraw_report_event(hid, data - 1, size + 1);
-		else
-			hidraw_report_event(hid, data, size);
-	}
+	if (hid->claimed & HID_CLAIMED_HIDRAW)
+		hidraw_report_event(hid, data, size);
 
 	for (a = 0; a < report->maxfield; a++)
 		hid_input_field(hid, report->field[a], cdata, interrupt);
#1 lore raw
Quoted 2 lines · Alan Ott

Make hidraw not stick an extra byte on the beginning of an IN transfer when a HID device contains multiple reports.

...

Quoted 2 lines

I have attached a patch which seems to take care of this problem. Please let me know if I have completely misjudged the situation.

Nope, your analysis is correct. It was introduced by me in 85cdaf524. I apparently forgot to change the hidraw case, so your fix is OK.

Quoted 20 lines
drivers/hid/hid-core.c +2 -7
index 2e2aa75..0e4a6fb 100644
@@ -1043,13 +1043,8 @@ void hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size,
 
 	if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
 		hid->hiddev_report_event(hid, report);
-	if (hid->claimed & HID_CLAIMED_HIDRAW) {
-		/* numbered reports need to be passed with the report num */
-		if (report_enum->numbered)
-			hidraw_report_event(hid, data - 1, size + 1);
-		else
-			hidraw_report_event(hid, data, size);
-	}
+	if (hid->claimed & HID_CLAIMED_HIDRAW)
+		hidraw_report_event(hid, data, size);
 
 	for (a = 0; a < report->maxfield; a++)
 		hid_input_field(hid, report->field[a], cdata, interrupt);
Signature · 1 line
js
Acked-by Jiri Slaby
#2 lore raw
Quoted 9 lines · Jiri Slaby
Quoted 2 lines · Alan Ott

Make hidraw not stick an extra byte on the beginning of an IN transfer when a HID device contains multiple reports.

...

Quoted 2 lines

I have attached a patch which seems to take care of this problem. Please let me know if I have completely misjudged the situation.

Nope, your analysis is correct. It was introduced by me in 85cdaf524. I apparently forgot to change the hidraw case, so your fix is OK.

Yeah, the analysis is correct, thanks a lot for catching this Alan!

I have put

to the patch and applied it.

Thanks,

Signature · 2 lines
Jiri Kosina
SUSE Labs, Novell Inc.