So after several years of existing out-of-tree, we’re finally making some headway with landing lirc in the upstream Linux kernel. As of 2.6.36, the core lirc device interface (lirc_dev) driver will be merged. We also have a new in-kernel IR protocol decoding infrastructure, currently dubbed “ir-core” (possibly to be renamed to “rc-core”, reflecting a desire to generically support remote controls using signaling other than infrared), which allows for zero-configuration, works just like a keyboard remote control support, right out of the box. IR decoders are “plugins” to this new infrastructure. I’ve also ported the old lirc_imon and lirc_mceusb drivers to this new infrastructure — the “imon” driver is in 2.6.35, the “mceusb” driver will show up in 2.6.36. So what good does this do without any lirc_foo device-specific drivers, you ask? Well, for one, all the current lirc_foo drivers will be able to be built out-of-tree against an in-kernel lirc_dev. I’ve also put together some entirely new code, in the form of an ir-core IR decoder plugin, which bridges between any in-kernel raw IR decoding driver and lirc_dev. This means that while out of the box, the mceusb driver and stock remote Just Work(tm) via the Linux input layer, you can *also* choose to pass the raw IR along to the lirc decoder plugin, which allows you to use lirc exactly as you would have with lirc_mceusb — decoding done in userspace via lircd. Calling the lirc plugin a decoder plugin is also a bit misleading. Its actually bi-directional codec bridge, meaning you can *also* transmit IR via the blasters on the mceusb devices using the mceusb driver with the lirc decoder plugin.
So what’s next? Well, I’ve got some work to do to make the lirc userspace happy with this merged in-kernel lirc_dev, as there were some assorted interface changes required to make lirc_dev suitable for upstream inclusion. After that, I plan to submit most of the current lirc_foo drivers into the Linux kernel staging tree, building against the in-kernel lirc_dev, but with a caveat that they’re all being put there with the intent that they be ported to the ir-core interfaces, or dropped entirely. I plan on working on as many of these as I can myself, but if they’re in staging, hey, maybe some more people jump in and help.
We’re going to release lirc 0.8.7 Real Soon Now(tm) as the last “legacy”-ish lirc release (hopefully), then we’ll be hard at work (actually, I’m already working on) lirc 0.9.0, which should fully support the in-kernel lirc bits.