While the title may sound a tad cryptic, that matched my first impression about the new infrared remote subsystem used in Ubuntu 10.10 and kernel 2.6.36+ based distributions. In Linux 2.6.36, a new sub-system is introduced for remote controls. This subsystem is a partial replacement for lirc as it features complete IR drivers for numerous devices.
In reality, the glass is only half full as some IR receivers (and transmitters) deal with raw data. Writing universal drivers for such devices can be bothersome or even impossible, for example when dealing with universal receivers. As such, LIRC is not completely written off as it can be used to do userspace IR processing as it used to. The exact details are unknown to me as I have an SoundGraph iMon receiver (device ID 0038 – LCD), which does not deliver raw sensory input but rather complete scancodes.
When I upgraded from Ubuntu 10.04 running lirc 0.8.6 to Ubuntu 10.10 and lirc 0.8.7, the entire IR subsystem died on me. To my surprise, while the remote was dead, the LCD screen was working fine. Further inspection showed that the ‘lirc_imon’ driver was not loaded at all.
With the move to the new input layer driver for supported IR devices in the kernel, the new ‘imon’ driver (version 0.8 at the time of writing) no longer provides a ‘lirc0’ device. As such, lircd will fail when attempting to claim it and loading ‘lirc_imon’ (provided you still have it) will not work as the device is already claimed by the ‘imon’ driver.
The fastest way to get up and running again is as follows. The ‘imon’ receiver will now be a HID input device. I got the impression it would send keystrokes to a graphical application but I didn’t get that working. Instead, we will use ‘lircd’ again using a special driver called ‘devinput’. This driver reads the key strokes from the input layer device and converts them into LIRC events. All your LIRC capable programs will then use LIRC like they used to – we only need to use the new button names.
To find the iMon receiver in the list of input devices, lets create a udev rule to symlink to the device. This way we will not have to rely on obscure device names like ‘input1’. Make sure the device name matches whatever hardware you have. I inserted this rule in a file called /etc/udev/rules.d/99-imon.rules:
KERNEL=="event*", SYSFS{name}=="iMON Remote (15c2:0038)", NAME="input/%k", SYMLINK="input/imon_remote", MODE="0666"
Lets begin by stopping lirc if you still have it running. Next, reconfigure LIRC to use the devinput driver – when it asks which device you have, DOT NOT SELECT THE SOUNDGRAPH IMON but ‘Linux input layer (/dev/input/eventX)’. In the next screen select ‘None’ as you probably do not use a transmitter.
/etc/init.d/lirc stop sudo dpkg-reconfigure lirc > Linux input layer (/dev/input/eventX) > None /etc/init.d/lirc start
In case you are not using Ubuntu Linux, I will explain the key parts of the LIRC configuration. The /etc/lirc/lircd.conf file now has this part in it:
#Configuration for the Linux input layer (/dev/input/eventX) remote: include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput"
The lirc.conf.devinput file is a standard (generated) file with key codes as provided with LIRC. There is no need to manually set up a file with button scan codes as the new ir-core kernel subsystem will generate standard codes.
The file called /etc/lirc/hardware.conf has something like this in it:
REMOTE="Linux input layer (/dev/input/eventX)" REMOTE_MODULES="" REMOTE_DRIVER="devinput" REMOTE_DEVICE="/dev/input/imon_remote" REMOTE_LIRCD_CONF="devinput/lircd.conf.devinput" REMOTE_LIRCD_ARGS=""
All that remains is to use the new buttons in your LIRC capable program. For example, this is a part of my configuration of XBMC (Lircmap.xml) for use with the SoundGraph iMon receiver:
1 2 3 4 5 6 7 8 9 10 11 |
<lircmap> <remote device="devinput"> <hash>KEY_EJECTCD</hash> <play>KEY_PLAY</play> <pause>KEY_PAUSE</pause> <stop>KEY_STOP</stop> <forward>KEY_FASTFORWARD</forward> <reverse>KEY_REWIND</reverse> <skipplus>KEY_NEXT</skipplus> <skipminus>KEY_PREVIOUS</skipminus> <record>KEY_RECORD</record>... |