19

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)

| improve this question | |
  • 2
    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... – LassePoulsen Dec 31 '10 at 0:05
  • 1
    Btw, instead of cat you can use evtest which gives nicely parsed info. – 9000 Jan 21 '11 at 16:57
3

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.

| improve this answer | |
17

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.