LIRC, infrared remote control on Linux (with the Creative Live!Drive)

1. Introduction
2. Linux Infrared Remote Control
3. Configuration and first tests
4. Function assignment to signals
5. Programs control and IRKick guide



This howto has been written for the owners of a Creative live!drive, I am expecially referring to those models (like the sound blaster audigy platinum) that come with infrared support and remote control. Nevertheless, the fourth and fifth chapter are dedicated to irexec, lircrc, IRKick and to the generic remote control of programs; this means that those chapters are valid for every infrared remote control handled by LIRC, and can be useful for everyone.
The instructions described in the first three chapters could also work (but it's just a conjecture of mine) with the multifunction external hubs that come with the most recent models of sound blaster audigy. I would be glad if someone could try the setup with one of those, to check if it works, and then write me to tell his experience.

Ok, here's a real scenery: we have our nice audio front panel, with remote control, and we use the Linux operating system. We would like to make this remote control work, to perform simple tasks like handling audio reproduction (play,stop,next,previous,seek) or browsing a dvd or every other possible task (starting a program, shutting down the system, everything!).
As you can guess, we'll need the following components:

• kernel drivers, for the management of the infrared device;
• software that associates the received signals to the wished operations;
• eventually, plug-ins for the interaction with our favorite programs.

The first couple of requisites are satisfied by LIRC (Linux Infrared Remote Control), a very good software package that includes everything you need to setup, test and manage infrared devices. The third requisite mostly depends on the operations that we want to perform (and on the program that we want to control).



LIRC comes with a large documentation, that covers its compilation and installation too. More, the selection of the driver (that will be compiled) can also be done with a simple script, setup.sh (dialog-based). Overall, setting up LIRC is quite simple.
In our special case (live!drive), things become even easier because we do not need to compile a kernel module. The live!drive can be controlled by the alsa emu10k1 driver (snd-emu10k1), and most likely we already have it, since our audio card is a sound blaster live/audigy. The snd-emu10k1 infrared support can be enabled by giving a extra parameter at module loading time. To automate this procedure, we'll add the following line in /etc/modprobe.conf :

options snd-emu10k1 enable_ir=1

Eventually, if we already have some custom options for the snd-emu10k1 module, we'll add enable_ir=1 to those options. Now we can concentrate on LIRC compilation. Here's the configuration:

./configure --prefix=/usr --sysconfdir=/etc --disable-static --with-driver=livedrive_midi --with-major=61 --with-port=none --with-irq=none --with-x

Of course, some of these options can be modified to suit special needs (in example, you won't use --with-x if you don't want to compile X Window programs). As you can see, we are not telling anything about the kernel sources and modules location, because the driver we chose (livedrive_midi) doesn't need extra modules. Done with the configuration, we proceed with make and make install. A couple of special files (a socket and a fifo) will be created during the installation process, unless they already exists. They are /dev/lircd e /dev/lircm.

A special notice for Slackware Linux fans: In the miscellaneous section of develia.org there's a precompiled tarball of LIRC, with the livedrive_midi driver, that also ensures that the two special files are created if they do not exists; how convenient! Of course, if you do not use Slackware (or want to try different configurations), the way of self-compiling remains a valid alternative.



First, if you want to use the infrared device as a simple user and not only as root, you must consequently modify the permissions of /dev/lircd. A possible solution could be to create a group "infrared", set the group ownership of /dev/lircd to this group, set 660 as file permissions (read/write for owner and group) and add the wished users to the group. Or you may simply set to 666 the file permissions (read/write for everyone).
Ok, up to now we have enabled the infrared support on the snd-emu10k1 driver and installed the LIRC package that includes lircd (the daemon that handles infrared signals) and many other programs. Needless to say that lircd is the most important program and our next step will be to configure it, making it able to correctly interpretate the signals received from our remote control.

The lircd configuration file is /etc/lircd.conf. Usually, the knowledge of its syntax is not important; anyway, curious people will be able the understand the various parameters by reading this guide to the file syntax. What you really need to know is that a proper configuration file is trivial for the correct working of the infrared device.
The proper lircd.conf can be obtained in many ways. With a bit of luck, the proper file may have already been installed along with lircd and other programs. In any case, there's a huge amount of configuration files for all those remoted control devices that are known to work with LIRC. From the complete list, move in the creative directory and get the configuration file relative to your remote control (I have a RM-900, but while I'm writing there are also config files for the RM-1000 and RM-1500 devices). So, get the file with the name of your remote control and put it as the new /etc/lircd.conf. You can also use more than a remote control device, by simply concatenating the relative configuration files in the same lircd.conf.

In the unlucky case that there isn't any configuration file available for your remote device, you'll need to generate one. This can be done with the irrecord program (it comes with LIRC too), for more information you can read its man page.

Assuming that we have a /etc/lircd.conf that suits our remote control, we'll want to do some tests to check if it works. First, we'll have to start the lircd daemon, with the proper parameters:

/usr/sbin/lircd -H livedrive_midi -d /dev/snd/midiC0D1

The parameters are quite self-explicative: the first tells lircd to use the livedrive_midi driver, the second tells lircd where's the device that should be used to get the infrared signals. I got the important information about the correct dev that should be used, thanks to user contributions on the alsa emu10k1 page.
After starting the lircd daemon, we can try the proper working of our remote control thanks to a handy test program, irw. This program simply prints on the standard output the data received from a unix domain socket. We could specify the socket, but we'll start it without any parameter, since /dev/lircd is the default socket for irw test, obviously.

So let's start irw and let's press some buttons on our remote control. If everything has been correctly done, we should see on the screen some information about the button we have pressed. Congratulations, you have a working infrared device on Linux!



At this point, in order to show how we can associate various functions to the buttons of our remote control, we should examine another configuration file, called lircrc. This file can be both system-wide (/etc/lircrc) or located in users' home (~/.lircrc), so every user of a system can customize it. The system-wide file will be read if there's not a user lircrc available. The syntax of lircrc is widely described in the documentation. For details, read there.
Instead, let's see how we can start some programs by clicking some buttons on our remote control; as you can guess, these programs should be started in some way. The software that does this work is irexec, another program of the LIRC package. The irexec program can be started as a daemon (in background), by simply passing the --daemon option at launch time. This option can become useful if you want to start irexec in a init script (like lircd). When irexec starts, it tries to read ~/.lircrc if it is available. For more information, refer to the man page of irexec.
Before starting irexec, let's add the proper lines in lircrc.


Then we start irexec, so that it can read our modifies. The lines above are quite easy to understand. The program (prog) that will handle the event is irexec; then we tell which button will trigger the event (the button names are those specified in lircd.conf); last, config contains the string that will be passed to the program chosen with prog. As you can see, the buttons left, right, stop of the remote control have been used to launch gimp, to launch abiword and to shutdown the system (assuming that the user has enough privileges to do it). Let's see a more complex example.


We learned something above, so we can say that irexec will launch xmms when the start button is pressed. The most important difference is the mode parameter. The mode parameter tells to the program that the next signals coming from the remote control should be handled in a special context (usually, they should behave differently within a program that we want to manage with remote control, like a media player). The flags parameter allows to specify some special options. For more information, refer to the official documentation.
In simple terms, pressing the start button on the remote control will launch xmms and will activate the xmms mode, of course it should be described in lircrc:


After the activation of xmms mode, the followed directives are those of reproduction (with the play button), pause (with the slow button) and so on (I added only three buttons in this small example).
In detail, you can see that the start button of the remote control has been redefined in the xmms mode. While we are in xmms mode, pressing the start button won't launch xmms again (as we could expect), but will send the QUIT string to the xmms program (terminating it). This will also quit the xmms mode (thanks to the mode flag). This means that the next time we'll press the start button, xmms will be started again (and the xmms mode will be enabled again, too). Simple and useful.

Now we know how to start programs (and how to perform various tasks, like shutdown, reboot, or starting internet connections) by using irexec and writing the proper lines in lircrc. Usually using the mode parameter is not necessary, unless you want to assign different functions to the same buttons, to modify their behaviour for different contexts (like different running programs, just like we have seen in the above example).

A smart question you could have, at this point: how did I choose the strings for xmms (PLAY, PAUSE, QUIT, etc.) to remotely control it? Where did I read about these strings? Are they documented? Does xmms always supports these strings?
Here's the simple reply: xmms doesn't natively support infrared, but there's a plugin, xmms-lirc, that makes possibile to control it by sending some strings. And these strings are described in detail in the documentation of xmms-lirc. Another useful information: you do not have to start irexec if you want to control a program with LIRC support (like xmms with xmms-lirc), as long as the program is running. Of course, you need irexec if you want to remotely start the program while it is not running.
Usually, in order to control a program, one of two conditions must be met: the program must be equipped with support (native or plugin) for LIRC strings, or the program must be equipped with an interface that allows it to receive external commands (like DCOP for KDE programs), and we'll use that with irexec. We'll review this second case in the next chapter.



Let's suppose that we have a media player called foo, and we want to remotely control it. Our player foo hasn't got any LIRC support, but it accepts generic instructions, for its single instance, from the command line; like foo --play or foo --stop. In this case, via irexec, we already know how to remotely control our media player, even if it doesn't support LIRC.

Things become much more interesting with those programs that have some interface that are externally accesible, like DCOP for KDE programs. DCOP is a interprocess communication system; I won't go deep in this argument, since it goes beyond the purpose of this guide. Anyway, even if you don't know much about DCOP, you can use it to control a program from "outside". A similar mechanism probably exists for GNOME as well, it should be CORBA/ORBit but honestly I have small experience with that.
So, we said that we can communicate with a lot of KDE programs via DCOP. We'll use kmail, the KDE e-mail client, for our example. Let's suppose that we want to use a button of our remote control to check if there are new emails in our boxes.
We need to know the kmail functions that we can access via DCOP, we can do this with the handy program KDCOP. This program lets us browse the DCOP functions available in running programs. So let's start kmail and in KDCOP we'll see which kmail functions are externally accessible. We find kmail.KMailIface.checkMail(), it is exactly what we need for our mail checking.
From a console, to launch this operation, we would write:

dcop kmail KMailIface checkMail

In lircrc, everything we have to do is add a voice like this one:


With the same principle we can control almost every KDE program. We can start them with irexec and we can perform some action in the program by using irexec (again) to send DCOP commands to the program.

The system we used depends on irexec and even if it's versatile and can be used in a lot of different situations, it is not the most simple and comfortable in KDE. On KDE there's a program called IRKick, that practically does all those things that we learned to do with lircrc and irexec. But it is much more simpler and intuitive. IRKick is the KDE LIRC server, it works along with lircd and doesn't need lircrc and irexec.
Once you've launched IRKick, you'll find its icon in the KDE tray. By clicking there, you can configure it. In the configuration window, you'll see a list on the left, that contains all the remote control devices that we have configured. We can add one using the Add button, and we can also set some special options, like those modes we have described for lircrc. On the right, there's a list of the operations associated to the buttons for each remote control (and for each mode). By clicking on the Add button, we can add another association button-operation. The operation can be the launch of a program or the remote control of a program (play, pause, stop, whatever). More, the remote control can be performed in a generic way via DCOP (just like we saw before) or by using proper extensions made available by the program (like we saw for xmms-lirc).
These extensions are generally available on multimedia programs (after all, those are the most suitable programs for a remote control). In example, kaffeine, amarok and noatun have these extensions. But konqueror has got them too. It is possible to review the list of installed programs that have these extensions by clicking on the loaded extensions tab in the IRKick window.


This sample image shows a IRKick configuration. Different operations have been associated to the buttons of the RM-900 remote control. Mostly are related to reproduction control in amarok (using the extensions that the program provides), but there's also the mail checking with kmail (done via DCOP).
As I said before, I guess that there's something similar for GNOME as well. Overall, there are really a lot of possible configurations and usages of infrared devices on Linux, thanks to the very good LIRC and to all those programs that work with it.


This HOWTO has been written by Giacomo Lozito, alias the maintainer of develia.org, with patience and passion.
If someone finds the howto very useful (in example, for a website dedicated to infrared and wireless on Linux), he's free to publish it on his website, as long as he keeps these credits unmodified (link to develia.org included) and he's so kind to let me know about it by email.
All the trademarks, company names and products mentioned and/or illustrated in the howto (like the Creative live!drive and the sound blaster audigy) are the property of their respective legitimate owners.