Jarod's Junk Collection

The Hauppauge HD PVR has been a supported video capture device under Linux for quite some time now. The MythTV 0.22 release officially added support for it as a capture device under Linux. However, because the HD PVR records via an analog input, not via a tuner, you need a way to change channels on the device feeding it. The HD PVR has a built-in IR receiver and transmitter, sitting on an i2c bus on the device, not unlike a number of other Hauppauge devices. Well, with a wee bit of hacking on the hdpvr driver and the lirc_zilog driver, we *can* enable the IR part and use lirc with it.

Here’s a patch against the hdpvr v4l/dvb driver to enable the IR part:
* http://wilsonet.com/jarod/junk/hdpvr-ir/hdpvr-ir-enable.patch

Then you need lirc_zilog, which isn’t in the upstream lirc tree due to concerns over its use of a ‘firmware’ image for its IR transmit tables. I’m maintaining lirc_zilog in my lirc kernel driver git tree though:

* http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=tree;f=drivers/input/lirc;hb=HEAD

Note that lirc_zilog started out as a rename of the old lirc_pvr150 driver, which started out as a fork of lirc_i2c, maintained by Mark Weaver, with details on it in his blog. lirc_zilog has been updated for use with newer kernels and more devices though, while the original is only targeted at the PVR-150 and no longer builds on current kernels. Another thing to note is that kernel 2.6.31 introduced a ton of i2c changes, so the lirc_zilog from my git tree won’t work with kernels prior to 2.6.31 anymore, unless you back out the i2c changes.

Once you have the driver built, there are still a few more steps to get things working. Oh yeah. Note that if you’re running Fedora 12 and its latest kernel, you don’t need to worry about any of the above, I already patched all the necessary bits into the Fedora kernel.

Either way, you still need a firmware image, a config file and some scripts to figure out which config stanza you need. Mark’s page includes links to the ‘firmware‘, which is really just a signal lookup table, extracted from the Windows driver. This file needs to go into /lib/firmware/ or wherever it is your distro puts kernel driver firmware images (any sane distro, it should be /lib/firmware these days). At this point, you should be able to load the lirc_zilog driver successfully and without any oopses (I still need to make it so the driver doesn’t oops if the firmware image isn’t found…). To be perfectly clear: the transmitter cannot transmit arbitrary IR commands, only those for which there’s a mapping in this pseudo-firmware table. If your device isn’t in the table, its probably not going to work. At least, not without a newer lookup table. A recommended step to take if you can’t get it working is to try under Windows with the latest Windows driver, which may have a newer table. If that works, we’ll probably want to get that table extracted from the Windows driver and make it available for the Linux driver to use.

Again, we’ll defer to Mark’s page, which includes a link to an lircd config file for the IR blaster to get you started. This file contains config stanzas for every device supported in the binary-only lookup table (aka ‘firmware’) you’ve loaded into the driver. Download it, drop it into /etc/lirc/lircd.conf, and start up lircd. Now you need to figure out which config stanza is the correct one for the device you need to transmit IR commands to. At this point, you should also be able to run irw, and see key presses registered from the flimsy little grey remote included with the HD PVR. Anyhow, back to figuring out the correct device… For me, the simplest thing to do was simply look at the table Mark put together and pick out the closest match to my device — which is cable box codeset 85 for the Motorola DCT6200 (I actually have a QIP6200, but same difference). If its not obvious at a glance which codeset you need, grab Mark’s script to cycle through sending the power button code for each possible config until it happens upon the right one. Once you’ve found the right one, you can edit /etc/lirc/lircd.conf, and strip out all the codesets that *aren’t* the right one. The last step is to then wire up a channel-change script in MythTV for your HD PVR capture device to use. Once again, we turn to Mark, and his channel changer, which you’ll simply need to edit to make sure its using the right codeset.

If during the above, or any time after, you’re having trouble getting any IR transmissions to register, there are a few things to note. First up, the transmitter should light up with each irsend command. If yours isn’t lighting up, its not properly connected, broken, or the driver isn’t actually working. Second, the transmit range is REALLY short, the transmitter needs to be positioned quite precisely over the reception target, or its not going to work — even a few centimeters to the left or right of the reception target, and its probably not going to work.

Now for the big caveat emptor: I believe at this stage, very few (if any) people have been able to actually use the IR part on their HD PVR under Linux reliably. At some point or another, while in the middle of video capture, the device completely deadlocks, and has to be reinitialized. Looking into the root cause of this is on my TODO list, but its a long list…

Ugh. Seems lirc_i2c doesn’t like to work when running the latest Fedora 11 kernel. I fixed the problem in 12, but never got the fix into 11, apparently. And in the latest pushed update kernel for Fedora 12, lirc_serial blows up (while it works in 11). Prime example of why we need to finally get lirc upstreamed, dammit… Anyway, the latest Fedora 11 and 12 2.6.32.x kernel builds have *both* fixed, so if you need either/both, try updating to that — they may be in updates-testing, or you may have to grab them straight out of the Fedora build system, not sure right now…

So the Linux Infrared Remote Control project has been around for 10+ years now, with kernel modules that have never ever been incorporated into the Linux kernel. Back in September of 2008, I posted all current lirc kernel drivers on the Linux kernel mailing list (aka lkml). Got tons and tons of feedback, mostly things that needed fixing. (And this was after myself, Eric Sandeen, Janne Grunau and a handful of other people to a lesser degree, spent a bunch of time and effort simply cleaning up the code to meet kernel coding standards — see scripts/checkpatch.pl in the linux kernel source tree).

So anyhow, I said thanks much for the feedback (particularly that from Jon Corbet), but hold off on further reviews until we address everything brought up so far, and we’ll resubmit a smaller set of patches for the best of the drivers to keep from being overwhelmed (18 drivers at once was probably a bit much…). Fast-forward slightly over a year. Took way longer to get round two posted than I would have liked, but in October of 2009, I posted just lirc_dev, lirc_imon and lirc_mceusb. Largely no response for a few weeks, then an explosion of north of 250 emails over a couple of weeks bouncing back and forth about how we should do IR in the kernel…

Basically, there are two ways to do things:

1) decode the IR signal inside the kernel and map it to an input subsystem key, i.e. map the IR signal for the Volume Down key on your remote to the input subsystem’s KEY_VOLUMEUP.

2) decode the IR signal in userspace (using lircd) and do with it as you please (ultimately, you can do the exact same thing as #1, but it requires a userspace process and configuration).

So now, one camp insisted that in-kernel decoding was the only true way to do things, because then it’ll Just Work with no configuration required. Except when it doesn’t… See, many IR receivers can handle a myriad of IR protocols and work with nearly any remote control. And an IR signal of protocol X may map to key Y on remote Z, but protocol X may map to key F on remote Q. There is, of course, some low-hanging fruit, where we can set things up to Just Work for the default remotes for a number of receivers, but that winds up being a somewhat limited set of devices — and sometimes the same receiver can be bundled with different remotes. In short, its a mess trying to support everything Just Working. The other major issue on this side of the fence is that userspace decoding requires adding new kernel interfaces and/or significantly altering the existing ones to support IR.

The other camp insisted that in-kernel decoding was a horribly bad idea, and that it should always be done in userspace, mostly because of the aforementioned issues. You’ll just never always get it right, and making changes in userspace is easier for users (imagine that). This is the way lirc has been doing things for 10+ years. Which means, by now, most of the kinks have been worked out (outside of automagic configuration).

I like to play the role of diplomat. And I can see uses for both. So what I *want* to do is work towards a hybrid approach, where driver authors can have their devices support either in-kernel or userspace decoding, or even both, leaving it up to the user to pick which one they want (defaulting to in-kernel, of course, since it ought to be possible to make that Just Work for receiver’s stock remote). The lirc interface and userspace daemon has proven itself stable and reliable over the years, so that’s what we ought to move forward with as the way for doing userspace decoding — we can even feed key presses back into the input subsystem via uinput, if so desired. And for in-kernel decoding, we’ll need to add protocol handlers for at least the major IR protocols (RC5, RC6, NEC, Sony, JVC and a handful of others — see http://www.sbprojects.com/knowledge/ir/ir.htm for a wealth of information on various protocols).

I actually had the SoundGraph iMON driver supporting something of a hybrid approach when I submitted version two of my patches. However, the iMON devices (at least, all recent ones) do onboard decoding, so there isn’t actually any raw IR that can be passed to the lircd userspace, only already-decoded hex values. That being the case, I completely gutted the lirc_imon driver, and it now (at least in my git tree) only supports the really old iMON devices that do pass raw IR, while the recent iMON devices (found in many HTPC cases) are now supported by a pure kernel input layer driver called simply ‘imon’, which I submitted for kernel inclusion a few weeks back (need to get back on that, see if I can figure out what’s holding up it getting merged).

So next up on the docket, after a detour reworking lirc’s core kernel interface driver to support the new kfifo api in linux kernel 2.6.33, is to get lirc_mceusb and maybe one more driver back up to snuff, and submit a version 3 patch, this time for inclusion in the drivers/staging/ tree. There’s some concern that once we add the lirc device interface, it’ll be set in stone, but if we bring it in via staging, its implied that the interface isn’t yet set in stone, so we can alter it if need be. But again, its been around for 10+ years, so I suspect there isn’t much that’ll require changing.

The current work-in-progress stuff can all be found in the kernel git tree I maintain up here: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=summary.

Its also patched into the latest Fedora kernels. Now I just need the time to finish up that v3. And some more sleep.