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
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
