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:
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:
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.
- /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″.
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 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.