May 02 2011

iMON

jarod @ 16:56

iMON, Linux and You

First up, please do NOT send me personal email asking about this hardware. I’m not your personal tech support, and your mail is quite likely to be ignored. If you have questions, concerns, corrections, whatever, send them to the lirc mailing list or the linux media mailing list. There’s a good chance that I will answer your question(s) on either of those mailing lists though. There’s also a chance others might have the answer, and regardless of who answers, the answer may be of help to more people than just you — and it will be archived for posterity, indexed by the almighty Google.

History:

There was a driver, lirc_imon, included in the lirc source distribution for quite some time. It was a bit of a train wreck, but mostly worked for basic usage. However, most iMON hardware doesn’t actually pass along raw IR signals. It decodes them in hardware, and passes along internally generated scancodes. As a result, passing data out to the lirc userspace via an lirc character device (e.g. /dev/lirc0) really made no sense. Plus, lirc_imon was riddled with races, lacked support for all hardware features, and wasn’t something even close to mergeable in the upstream kernel tree.

Current:

Fast-forward to Linux kernel 2.6.38, which is the latest release from Linus’ tree as of this writing. There’s now an in-kernel driver for iMON hardware, simply called ‘imon’.  Its written using the in-kernel rc-core (remote control core) infrastructure, and presents two input layer devices to userspace, one for the remote’s mouse mode, and one for keyboard (remote) mode. All decoding and keymapping is done in the kernel. There is no lirc character device access to this hardware any longer, and its not coming back.

However, you *can* still use this hardware with the lirc daemon, if you wish to do so, and in fact, it may be necessary, due to limitations of the X server’s prehistoric keycode support and/or applications that do not support key remapping any way but via lirc configuration files. The lirc daemon has various “drivers” itself — the “default” lircd driver connects to an lirc character device. The “devinput” lircd driver connects to an input layer event device, which is what the imon driver exposes. Out of the box, the remote should be in keyboard mode. If you hit the keyboard/mouse toggle button, the directional pad moves your mouse cursor, the mouse buttons are, well, mouse buttons, and channel up/down serve as a scroll wheel. Hit the keyboard/mouse toggle again to go back to keyboard mode. Because mouse mode uses a different input device, you can capture just the “keyboard” side with lirc by grabbing its input device, and let the mouse input device continue to function as a mouse.

Simply configure lircd to use the “devinput” driver, with the corresponding lircd.conf.devinput either referenced as your config file, or copied to /etc/lirc/lircd.conf, and point at the by-id input layer symlink for your imon device’s remote/keyboard interface, which should be the one in /dev/input/by-id/ that ends in -if00, such as /dev/input/by-id/usb-15c2_0045-event-if00 (an Antec Veris Premier LCD/IR device). Use the by-id symlink instead of a /dev/input/eventX device directly, as the X may vary from boot to boot, or even within a single boot, if you add or remove usb devices. The symlink should remain constant.

That’s really all there is to it[*].

[*] Okay, not entirely. If you want to use an RC-6 Windows Media Center remote (or a universal programmed as such) and you have one of the newer imon devices that supports both iMON remotes and MCE remotes, you’ll need v4l-utils, which contains ir-keytable and /etc/rc_maps.cfg, which you will have to edit so the rc-imon-mce keymap gets loaded. This will have no impact on iMON devices with usb device ID 0xffdc, as they only support one mode or the other to begin with, and should be auto-configured accordingly.

Leave a Reply

You must be logged in to post a comment. Login now.