Re: Still Problems with USB Remote control

On Tue, 27 Feb 2007, Guenther Sohler wrote:

> Yesterday evening I was able to play with my remote control again and 
> I'd like to share a small success story with you.
> In drivers/input/input.c in input_event I found following code
> 
> if(dev->sync)
>         return;
> dev->sync=1
> So I just received just the very first event. After that the function
> returns prematurely and NEVER gets to the COMMON event call at the body
> of the function. 

This should only happen once per report, at the time that all fields from 
the received report have been parsed and passed to the input driver as 
EV_KEY (or anything else, according to the existing mapping in hid-input).

For every field received in report, the callchain is hid_input_report() -> 
hid_input_field() -> hid_process_event() -> hidinput_hid_event() -> 
input_event() with values obtained by parsing the field in received 
report.

After all the fields have been passed through input_event(), input_sync() 
is called from hid_input_report() -> hidinput_report_event(), which is OK 
- at that time, all the received fields should have already been passed to 
the input event handler.

> After commenting those code and compiling again, I really got a EVENT for
> EVERY keystroke :) I was very hapy about that.

I still don't fully understand where do the events get lost in your case. 
One possibility is that the machine is having a broken report descriptor, 
resulting in the fields in received reports not being parsed correctly 
(this wouldn't really be the first case of such a broken device). 

> You told me to send you all that debug information. It was not so easy 
> for me, because I was only able to activate debug by uncommenting #ifdef 
> DEBUG lines. and printing /proc/kmsg .I do NOT know, how to change the 
> linux but I still got some debug
> report (size=4) unnumbered
> report 0(size=4) 40 00 19 0f

This is fine, but a bit more of messages would be needed, namely:

- report descriptor dump. This gets printed (in debug mode) upon the 
  device connection. The dump should basically resemble 

  drivers/usb/input/hid-core.c: report descriptor (size 59, read 59) = 05 
  01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 75 01 95 08 81 02 81 03 95 
  05 05 08 19 01 29 05 91 02 95 01 75 03 91 01 95 06 75 08 15 00 26 a4 00 
  05 07 19 00 2a a4 00 81 00 c0

- hid-input mapping. The respective dump should resemble

   INPUT[INPUT]
     Field(0)
       Usage(8)
         Keyboard.00e0
         Keyboard.00e1
         Keyboard.00e2
... etc, then mapping dump, such as 
Mapping: Keyboard.00e1 ---> Key.LeftShift
Mapping: Keyboard.00e2 ---> Key.LeftAlt
Mapping: Keyboard.00e3 ---> Key.LeftMeta
... etc should follow

Thi achieve this, you have to enable HID and USB HID debugging. This is 
done by putting

#define DEBUG
#define DEBUG_DATA

at the beginning of hid-core.c and hid-input.c (both in drivers/usb/input 
and drivers/hid, if you are using kernel with generic HID layer 
(2.6.20-rc1 and later).

If you are using 2.6.21-rc1 kernel, the HID debugging can be turn on in a 
much more conventient way - it became a kernel configuration option.

-- 
Jiri Kosina

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel