linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/1] Bug in hidraw When a HID Device Contains Multiple Reports
@ 2010-04-26 22:34 Alan Ott
  2010-04-27  7:20 ` Jiri Slaby
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Ott @ 2010-04-26 22:34 UTC (permalink / raw)
  To: Jiri Kosina, Stephane Chatty, Marcel Holtmann, simon.windows,
	linux-input, linux-kernel

From: Alan Ott <alan@signal11.us>

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

Signed-off-by: Alan Ott <alan@signal11.us>
---

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.

>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.

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 2e2aa75..0e4a6fb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -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);






^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/1] Bug in hidraw When a HID Device Contains Multiple Reports
  2010-04-26 22:34 [PATCH 1/1] Bug in hidraw When a HID Device Contains Multiple Reports Alan Ott
@ 2010-04-27  7:20 ` Jiri Slaby
  2010-04-27  8:25   ` Jiri Kosina
  0 siblings, 1 reply; 3+ messages in thread
From: Jiri Slaby @ 2010-04-27  7:20 UTC (permalink / raw)
  To: Alan Ott
  Cc: Jiri Kosina, Stephane Chatty, Marcel Holtmann, simon.windows,
	linux-input, linux-kernel

On 04/27/2010 12:34 AM, Alan Ott wrote:
> Make hidraw not stick an extra byte on the beginning of an IN transfer
> when a HID device contains multiple reports.
...
> 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.

> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 2e2aa75..0e4a6fb 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -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);

-- 
js

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/1] Bug in hidraw When a HID Device Contains Multiple Reports
  2010-04-27  7:20 ` Jiri Slaby
@ 2010-04-27  8:25   ` Jiri Kosina
  0 siblings, 0 replies; 3+ messages in thread
From: Jiri Kosina @ 2010-04-27  8:25 UTC (permalink / raw)
  To: Jiri Slaby, Alan Ott
  Cc: Stephane Chatty, Marcel Holtmann, simon.windows, linux-input,
	linux-kernel

On Tue, 27 Apr 2010, Jiri Slaby wrote:

> On 04/27/2010 12:34 AM, Alan Ott wrote:
> > Make hidraw not stick an extra byte on the beginning of an IN transfer
> > when a HID device contains multiple reports.
> ...
> > 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 

	Acked-by: Jiri Slaby <jslaby@suse.cz>

to the patch and applied it.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-04-27  8:25 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-26 22:34 [PATCH 1/1] Bug in hidraw When a HID Device Contains Multiple Reports Alan Ott
2010-04-27  7:20 ` Jiri Slaby
2010-04-27  8:25   ` Jiri Kosina

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).