How to debug the input from an input-device (/dev/input/event*)
You may find useful xinput list
and xinput test <device>
.
For example,
$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ Asus Laptop extra buttons id=9 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
and I can monitor my keyboard (xinput test 10
) or touchpad (xinput test 11
, or even xinput test "SynPS/2 Synaptics TouchPad"
) for all kinds of input events, and they get pretty printed to console, and parameters get extracted and printed too.
This won't solve your problem, but at least will help a bit by deciphering the clutter which e.g. cat /dev/input/event1
produces.
I have the same remote and I have it sending correct keycodes to my 2.6.38-gentoo-r3 kernel. I did not compile keycodes as a module, because they probably haven't had time to make it possible to select individual keymaps yet. It's all or nothing and I don't like a gazillion useless modules cluttering me. Instead I'm letting v4l-utils handle it with udev.
Couple of things I learned:
- Check output of ir-keytable -r, it should list all the keycodes applicable to your remote.
- Load the keytable manually: ir-keytable -c -w bleh/keymaps/imon_pad, after which ir-keytable -r should give you the table back
- You might actually have a faulty receiver, you mention nothing about history. I remember seeing at least one message on lirc-list where guy said sending the case back and getting a new one solved his issues.
Let us know how it went.