gnome-lirc-properties: A GUI to configure Infra-Red Remote Controls

General, , ,

We at Openismus will be working on a little GUI control panel to configure remote controls, so you can more easily, for instance, control a media-center application such as Elisa. We are doing this for Fluendo.

It should end up looking something like this and it will basically just give you a working /etc/lirc/lircd.conf file for your remote control:

gnome-lirc-properties Screenshot

I’ll make a few posts about this, but first here’s some (opinionated) notes about how I think it works now on Ubuntu without this GUI:

Installing lirc

You select the remote control via a curses UI when you install lirc (or when you run sudo dpkg-reconfigure lirc). We would prefer it to install silently and let the user configure it when he wants to. I think the script for this is debian/lirc.config.in in the lirc debian package, though this doesn’t seem to be the whole story. It seems to use the prewritten configuration files in /usr/share/lirc/, listed in the /usr/share/lirc/lirc.hwdb file, which seem to be supplied only with Debian/Ubuntu.
This creates

  • /etc/lirc/lircd.conf, which maps the key names to the key codes supplied by your IR remote (usually assuming that you are using the IR receiver (if any) supplied with the IR remote control. It’s these key names that an application will receive via the liblirc_client library.
  • /etc/udev/rules.d/85-lirc.rules, which uses /etc/init.d/lirc, which starts “/usr/sbin/lircd –device=/dev/lirc0”.

Custom Configuration

When the lirc package does not know about your hardware, or if it has a bad configuration file, you can use the irrecord utility (installed with lirc) to generate a custom lircd.conf file, which you can move to /etc/lirc/lircd.conf. It checks for key codes and some other aspects of the remote control. Here is an example of an irrecord run. irrecord is a command-line utility which takes input on stdin. Doing this programatically is going to be difficult, probably requiring the creation of a libirrecord in the lirc sources.

Note that the default device for lirc is /dev/lirc, and it doesn’t check for other devices automatically, but applications don’t need to specify the device because they just communicate with lird via liblirc_client. However, the irrecord utility doesn’t use lircd so you’ll need to use the –device option with it too.

The application

The application then creates a .lircrc file (Elisa creates one in /tmp when it starts, and this seems the only sensible thing to do) which maps these key names to “command” names. This seems like a useless extra step because most applications will just invent “command” names which are identical (or near identical) to the “key” names. The entries in this .lircrc must use the same “prog” identifier string as the application has passed to the lirc_init() function – another annoying invitation to failure. This is presumably useful when using one .lircrc file to control multiple applications somehow, but I can’t see how that could ever be useful – a global .lircrc file could at the most be used to _start_ applications, not control them.

Update:: Of course, I do have the strong feeling that remote controls should be just another input device, like mice and keyboards, so the whole lirc daemon thing seems odd. But I’m not a kernel or X programmer. This might even be planned for the future, but I don’t know. We do need something to make lirc work easily now.

8 thoughts on “gnome-lirc-properties: A GUI to configure Infra-Red Remote Controls”

  2. Yeah lirc sucks :) But i’m no expert in kernel/X.

    appleir+hal+xorg 1.4+evdev seems to do this for me on a macbook pro. Works with no lirc.
    Hal can add various properties on previously probed input devices. (Like input.x11_driver). Xorg then loads the driver for the device (hal can set input.xkb* keymap properties as well). Empty xorg.conf + hotplug! :). So if the IR-Receiver driver export an evdev interface – lirc isn’t needed?

    Ofcourse if people use a custom IR remote control it’s not possible to auto detect everything as your gui shows.
    But does that matter for a default soltion? A real product should come with a remote designed for the gui? ;)

  3. There have been quite a few reports on the various planets (gnome/fedora/etc) that the remote that comes with the Dell m1330 just works and sends through key codes.

  6. Holy cow this will rock! Although to be honest, I’ve stopped using lirc for my ATI All-In-Wonder RF remote. The kernel module for it crashed all the time so now I’m just back to using the remote as an X input device. Of course, that works quite poorly as many of the buttons generate keysyms greater than X can process (or something like that).

  7. “Of course, I do have the strong feeling that remote controls should be just another input device, like mice and keyboards, so the whole lirc daemon thing seems odd. But I’m not a kernel or X programmer. This might even be planned for the future, but I don’t know. We do need something to make lirc work easily now.”

    This is allegedly already possible for i2c-based remotes, using the ir-kbd-i2c kernel module instead of the lirc stuff. I only tried once very briefly to use this and found it didn’t work, but that may have been related to more complex errors with my remote, so it’s possible it does work in most cases. Try it, anyway.

Comments are closed.