Remapping RaspBMC Remote Keybindings

I've updated my HTPC to be a Raspberry Pi that uses RaspBMC as the OS. The really hard part was integrating my existing RAID with the device (over USB) to serve up my media; that's a subject for another post.

Something that didn't quite work out of the RaspBMC box (and to be fair A LOT did work) was the Context Menu for XBMC. I like to call it the "right click" option if I was using a mouse. This was because my remote didn't have the default button that XBMC was expecting. As mentioned in a previous post I have a generic RC6 IR receiver that I had used the mceusb2 kernel driver. Looking at the remote config file for XBMC (/opt/xbmc-bcm/xbmc-bin/share/xbmc/system/keymaps/remote.xml) the ContextMenu is mapped to the <title> key. Looking in the LIRC config file for XBMC (/opt/xbmc-bcm/xbmc-bin/share/xbmc/system/Lircmap.xml) for a mceusb remote the "title" is mapped to the "Guide" key. Looking on my trusty remote diagram there was a Guide button, but why didn't it bring up the context menu?

Turns out that RaspBMC was using a different remote config in Lircmap.xml Using irw to see the remote codes I get:

16d 0 KEY_EPG devinput
16d 0 KEY_EPG_UP devinput

Searching Lircmap.xml for devinput I got a different <remote> profile, with no mapping for <title> So I added:

<title>KEY_EPG</title>

and the Context Menu is displayed.

Handy little util irw for figuring out remote config.

Writing config for LIRC

In my previous post, I got LIRC working with Gentoo. However the LIRC config comes in essentially two halves. The first is the mapping of the remote's IR frequency/signal to "buttons". So when I press play, the computer realises that I mean play. However how does the application know I mean play? That's where the second config comes in. It maps the buttons provided by LIRC (eg: Play) to application commands (eg: play <filename>). However there were two things I found while doing this that I thought were interesting.

Firstly, you have to put in the exact ASCII code into your app config that is emitted by your remote. Which is OK (and obvious), but occasionally you have pairs like Replay/Skip. Plus is VolUp Volup? Since I have a terrible memory I created a button diagram [PDF] that lays out the buttons and their ASCII codes. I created it using a photo of the remote that I took (I'm no photographer but it's usable), and GIMP/Inkscape. I prefer working with Vector graphics.

The second is that I found the LIRC config format to be very verbose and repetitive. With a large amount of config I could see it being difficult to understand what's going on. So I created my own (non sanctioned) meta syntax and a Perl script to turn that meta syntax into the proper LIRC config syntax. For example, take VolUp for mplayer

  begin
    remote = mceusb
    prog = mplayer
    button = VolUp
    config = volume 1
    repeat = 1
  end

The first three lines are going to be same for all the mplayer configs. It's the button, config and repeat options that are the interesting items for the VolUp command. In my meta syntax

# 
# The meta syntax is <, configvalue>*<; repeatvalue>*
# That is the button name with config values separated by , and
# repeat values separated by ;  The script will read everything
# between the separators and assign it to the appropriate
# key/value pair (eg config)
#
# Meta tags are fields that apply to the entire output
# (LIRC config) and currently stand as
# @prog - The program you are writing the config for
# @remote - The remote name
#
# The input may also contain comments (lines starting with the #
# symbol) to comment out buttons that may not be applicable to a
# program.
#

For the above example in the metasyntax I wrote

VolUp, volume 1; 1

Much more understandable (once you know what the separators mean of course). Coupled with the meta tags and the script, I generated an entire config for mplayer.

One could quite easily put different programs configs expressed in the LIRC meta syntax into different files which could then be run through the script and cat'd together into ~/.lirc which is where programs like mplayer and gxine, etc look for remote control configs.

All the files linked are licensed are essentially free. So do use them, play around with them if they will help you.

cat /dev/lirc0 > brain (getting LIRC working)

Due to lacking some hardware, I've postponed the connection of the HTPC box to the telly. So I thought I'd conquer the remote control problem. When I bought my laptop I got given a whole bunch of stuff that I thought I'd never use. Part of which was a remote control and an IR receiver. Very handy now. I looked up the LIRC Gentoo Wiki to get some idea of what I was needing to do. Turns out it wasn't so simple. My IR receiver plugs into the USB port, so I thought I would use the devinput LIRC_DEVICES option. Turns out that was a bad idea. I couldn't get irw to ouput any codes. I thought that maybe it was because I had a very empty mapping section in my /etc/lirc.conf So I tried using irrecord. That didn't work either. irrecord kept informing me that I wasn't pushing the button when my finger and the two red LEDs on the remote and the receiver seemed to suggest otherwise.

My next thought was that there was a problem with the USB subsystem. So I checked I had all the right stuff in the kernel. Tick. So I googled around for how to find out what's connected to the USB. Handy little program lsusb. It told me that I had a "Philips eHome Infrared Receiver". Checking the dmesg logs at /var/log/dmesg showed nothing wrong with the USB side of things. So what was going on?

Google once more to the rescue! Turns out that I had compiled the wrong LIRC driver (or no driver at all). Changing my LIRC_DEVICES to mceusb2 (and reemerging lirc) compiled the correct driver /lib/modules/2.6.31-gentoo-r6/misc/lirc_mceusb2.ko modprobing lirc_mceusb2 created /dev/lirc0 Testing it via irw I got some results

000000037ff07be9 00 Play mceusb

All that was left was adding the kernel module to /etc/modules.autoload.d/kernel-2.6, and adding lircd to the default startup sequence and I was done. A quick reboot to ensure that everything worked from the get go, and I had a working remote control. Turns out the running etc-update after reemerging lirc updated my /etc/lirc.conf with a config file for generic RC-6 remote; which is handy because on the bottom of the remote it's labelled "RC6" ;). It's nice that the ebuild for lirc copies the config for you upon install. Not hard to do it myself, but I like the ebuild doing the heavy lifting for me :)

Now I have to do some config to make sure that apps can respond to those bathroom break pauses during the extended Lord Of The Rings sessions :p

Update: next time I should check the Hardware4Linux site. Might save me some troubles.