How to debug the input from an input-device (/dev/input/event*)

Question

I have a IR receiver that is using the imon-driver and I would like to get it working with the kernel. Right now half of the keys on the remote (image) works, but an all important think like the numeric keys doesn't!

The weird think is that the kernel keymap module (rc-imon-pad) seems to be correct but it seems that it is not really used since excatly the same keys are working without that module.

It seems that the rc-imon-pad module always gets loaded when I load imon, and then I suspect that the keycodes are cached so it doesn't make a difference if I unload rc-imon-pad

Now I am lost, if I do cat /dev/input/event5 or ir-keytable -t there is data no matter what key I press, so the driver registers the buttons but it just seems that they are translated to the wrong keycodes.

My kernels is an ubuntu stock kernel from Natty (Linux xbmc 2.6.37-11-generic #25-Ubuntu SMP Tue Dec 21 23:42:56 UTC 2010 x86_64 GNU/Linux)

Solution 1

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.

Solution 2

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.

---

Edit (from @alphanum in comments):

I wasn't really precise in my 10-year old answer... apologies. Enjoy this quick diagram:

┌─────────────────────┐            ┌─────────────────┐               ┌──────────────┐    ┌──────────────────┐
│                     │ HID events │                 │ xinput events │              │    │                  │
│  HID/input device   ├───────────►│ Device-specific ├──────────────►│  the kernel  ├───►│ Userspace (apps) │
│ (e.g. USB keyboard) │    ▲       │     driver      │     ▲         │              │    │                  │
└─────────────────────┘    │       └─────────────────┘     │         └──────────────┘    └──────────────────┘
                           │                               │
                  evtest /dev/input/XX            xinput test <xinput id>

It shows 2 points:

• The results you get from xinput test are "xinput-unified"; i.e. processed by the device driver. These are more similar to what userspace apps see.
• The results you get from evtest /dev/input/XX are more "raw", not-yet-translated into xinput format. These are more similar to what your HID device will see.

Pertinent to whether you build a physical HID device, or an app, you may choose to use evtest or xinput test for debug. Comparing the 2 may also help troubleshoot device driver issues.

Comments

[Admin]

It seems the problem is that the kernel sends keycodes larger than 255 which X doesn’t register because it is limited to an unsigned 8bit integer. And I’m now recompiling the kernel module with modified keycodes to test this theory...

[Admin]

Btw, instead of cat you can use evtest which gives nicely parsed info.

[l0b0]

Thank you so much! I built a keyboard detector based on this answer.

[Elijah Lynn]

Make sure to check out this answer everyone, xinput test is very useful here. unix.stackexchange.com/a/6231/27902

[alphanum]

This will not directly give the /dev/input/XX events, but how these events are processed and turned into xinput events by the corresponding xinput driver. To view the real events emitted by the kernel input drivers, one can use "evtest /dev/input/eventX". This can make a difference, e.g. the synaptics touchpad in my laptop supports multitouch events, but the xinput method will only yield single-touch events as emitted by the xinput-synaptics driver.

[Julio]

Good point @alphanum, I'll edit that in if you don't mind.