LIRC

From Gentoo-en
Jump to: navigation, search

This page is outdated.

Reason given: LIRC's kernel bits are being moved to mainline. Things are in flux.

Please pay attention because the contents on this page are no longer up-to-date. This will mostly be because of updated ebuilds. If you encounter any changes while reading it, please edit this page according to the changes.

Introduction

LIRC stands for Linux Infrared Remote Control. It allows you to receive and send infrared signals. With LIRC and an IR receiver you can control your computer with almost any infrared remote control (e.g. a TV remote control). You may for instance control DVD or music playback with your remote control.

Linux Kernel Configuration: Linux Kernel Configuration: Kernel 2.6
Loadable module support  --->
   [*]   Module unloading
Device Drivers --->
   Input device support --->
      [*] Event interface
Warning: When you are using devfs or sysfs with your kernel, the /dev/lirc device node will disappear again once you reboot your machine. In that case the LIRC kernel module will generate the required entry every time it is loaded. But the device node will not be visible as /dev/lirc, but might be located in a different location like e.g. /dev/lirc/0. Please be aware of this fact when starting programs that access the device node like mode2 or lircd. You will have to use the --device command line option of these programs to point them to the correct location. When using sysfs together with the udev daemon you should copy the lirc.rules file located in the contrib directory of the source package to /etc/udev/rules.d/. This will make sure that the device node will be created.

Install

You need to set an environmental variable prior to compiling LIRC in order to install the appropriate drivers for your tv capture card. That means you will need to determine which of the following drivers is suitable for your card. For a list of all supported devices, run:
emerge --pretend --verbose lirc

Unfortunately, it is not necessarily straightforward which driver to use in all cases, as neither the LIRC project website nor the installed documentation seem to provide this information. In most cases, however, the product name should be one of the drivers. You should decide what type of receiver you are using. If not, only support for the homebrew serial receiver will be compiled.

Homebrew receiver drivers:

That is a lot of options. For those of you with a homebrew serial receiver, your option will be "serial". If you received a remote with your video card or TV tuner, you will need to choose the most appropriate driver from the list above. You can get some idea of whether your hardware is supported or not by checking the sidebar of the official LIRC website. For using the tvcard integrated controllers like Hauppauge, do not forget to compile your kernel with i2c support.

Once you have selected your driver, you need to set the LIRC_DEVICES environmental variable, or simply edit /etc/make.conf as follows:

File: /etc/make.conf
LIRC_DEVICES="driver"

If you have a serial IR device, set:

File: /etc/make.conf
LIRC_DEVICES="serial sir"

If your device is supported by the kernel, (uses /dev/input/eventX) you will need to use the dev/input driver instead. This works particually well for these devices:

  • X10/Medion/ATI remote controls (needs ati_remote kernel module)
  • Hauppage NOVA-T
File: /etc/make.conf
LIRC_DEVICES="devinput"

Or, if you don't mind the extra compile time, you can just tell it to compile all of them and let the kernel autoloader figure out which one to use:

File: /etc/make.conf
LIRC_DEVICES="all"

Now you are ready to (re-)compile LIRC:

emerge --ask --verbose lirc

It is useful to set the global USE flag lirc so that all applications are built with LIRC-support. Then recompile all applications whose USE flags have changed:

emerge --ask --verbose --deep --newuse world
.

Older versions of LIRC apply their sources to the kernel sources. By default configuration, it is not possible for an ebuild to overwrite kernel source files. In case that you are using such an ebuild, you can fix the issue with the following command:

config-kernel --allow-writable=yes
.

If the driver you selected is only available in kernel space, LIRC will compile it on installation. All LIRC kernel drivers require lirc_dev. You do not have to load it manually. It is sufficient to only load the LIRC kernel driver module since it has lirc_dev as dependency. If you do not know the exact name, go to /lib/modules/$(uname -r)/misc/.

Note: The driver modules compiled by LIRC will only work for the current kernel. If you upgrade your kernel, you also have to recompile LIRC.

Depending on your mix of kernel and LIRC versions, you can run into incompatibility issues. Especially the warning "Unknown symbol class_simple_device_add" indicates that you might have to switch versions. Try to get a more recent LIRC ebuild:

echo "app-misc/lirc ~arch" >> /etc/portage/package.keywords

If that does not help, upgrade your kernel and recompile LIRC.

Configuration

LIRC needs to know how to interpret the output from your remote. Codes from the remote are mapped to buttons in /etc/lircd.conf. There are two means of obtaining a lircd.conf file suited to your remote. For many (probably most) remotes you can simply copy the configuration file from the LIRC project website. However, if a prepared lircd.conf file is not available from the LIRC site, you will need to use the irrecord utility that is installed with lirc to capture the signals generated by your remote for each button.

Modules

If you want to use your remote control using an input device, add the module name to /etc/modules.autoload.d/kernel-2.6 (e.g. ati_remote) and skip this section.

Before starting LIRC, it is important load the necessary kernel modules.

Be sure you have unloaded all kernel modules that allows you to access the signals of your IR device in /dev/input. Use the LIRC modules instead. If you have a ATI/Medion/X10 remote control, you probably have the kernel drivers already loaded. Unload them with:
rmmod ati_remote ati_remote2

You may need to use an appropriate kernel module for your hardware to work properly. If so, you will have to add "lirc_driver" to your /etc/modules.autoload.d/kernel-2.6 file so the module can load during boot. Substitute "driver" in "lirc_driver" to the actual driver you are using, which was defined in the LIRC_DEVICES variable in your make.conf above. To enable serial support for instance, you would add "lirc_serial".

The appropriate modules will now be autoloaded when booting, but you should also activate them now:

modprobe lirc_gpio lirc_dev tuner evdev

Recording the IR-codes

You need to have a configuration file for your remote control that tells LIRC how to interpret the IR codes transmitted by your remote. If the key codes were already correct, you can move on with the next section. The easiest way to configure the IR codes is to use an existing config file, try finding your remote in this listing. If your remote is not listed you can try using irrecord to create the file. Or, if you are using a universal remote you can just program it to control for example a Sony TV set and then try any of the files listed under Sony. When you have found a config file save it to /etc/lircd.conf.

You can try to use a pre-configured IR-codes file. They are stored in /usr/share/lirc/remotes and copy the setup you want to try out over to /etc/lircd.conf.

If you do not have any success with this, you can create your own file. Use this command:

irrecord /tmp/remote
Note: While starting this you have to keep a button on your remote control pressed so that it recognizes the gap in which your remote control sends the signals until a message appears.

This might not work for you if you only compiled LIRC with devinput support. In this case you first have to find out the path for your remote control. It is best to write a command that find it out dynamically because it is very likely that these paths change. For X10, try this:

EV="/dev/input/"$( cd "/sys/class/input" && grep -l 'X10' event*/device/manufacturer | sed -e 's,/.*,,' )

Now execute it like this instead:

irrecord -H dev/input -d $EV /tmp/remote

If this will not work for you, try out if your command detected the path correctly by pressing some buttons on your remote control after running:

hexdump < $EV

This should produce output as the buttons are pressed.

Note: Do not use "cat" since it might garble your terminal settings

Then type in the names for each button (e.g. VOL_DOWN, CHAN_UP, MUTE, etc.). You need them later when running irexec.

If you are done, replace your /etc/lircd.conf with your just-created configuration file:

mv /tmp/remote /etc/lircd.conf
Note: If you are coming from Ubuntu or another Debian-based distribution, you can use its lircd.conf but not its /etc/lirc/ directory with the hardware.conf because on Gentoo you have to set the parameters for lircd manually in /etc/conf.d/lircd.

Testing the receiver

Now it is time to check your configuration.

Stop any running lircd

Ensure that the daemon is not running before starting a new one.

/etc/init.d/lircd stop

or

killall lircd

Run lircd

For devinput start lircd, as follows:

lircd -n -H dev/input -d $EV

Otherwise, just run:

lircd -n

If it does not work, try to set the correct path to your device ():

lircd -n -d /dev/lirc
Note: Make sure the correct LIRC modules have been loaded as per the Modules section above
Note: Do not forget the -n parameter because otherwise LIRC will start in background and will not print out all debug messages.

Please make sure that you use with the correct device above, otherwise you may experience "Connect: Connection refused" errors when trying to access the LIRC device. For example /dev/lirc0 rather than /dev/lirc/0.

Test setup

If lircd did not print any error messages, you can run either of these 2 methods to test your setup:

Method 1

irw

If everything is correct this will connect to the lirc device and echo the buttons you have pressed. Press all buttons to check whether all events are triggered properly. It should print your out the codes you set in your lircd.conf.

Method 2

Verify that you have a new device node:

ls -l /dev/lirc*
Check that the LIRC device has been created at /dev/lircd. Test that you are actually receiving data from your remote by running:
cat /dev/lirc0
while pressing buttons on the remote. This essentially accomplishes the same thing as method 1. You should see data being received by the device each time you push a button.
Note: This method only works for non-devinput devices.

Save setup

Then edit /etc/conf.d/lircd with these parameters. For devices using the input-layer it might look like:

File: /etc/conf.d/lircd
EV="/dev/input/"$( cd "/sys/class/input" && grep -l 'X10' event*/device/manufacturer | sed -e 's,/.*,,' )
LIRCD_OPTS="-H dev/input -d $EV"

Restart lircd in normal mode

Now start up LIRC and add it to the default runlevel so it starts on the system's start:

/etc/init.d/lircd start rc-update add lircd default

Configuring ~/.lircrc and irexec

~/.lircrc is the config file used by programs with native LIRC support (mplayer, xine-ui, ... with USE="lirc") and by irexec for the other applications (tvtime, xmms, ...) to execute commands in response to data captured from the remote. It is your personal button configuration file which maps buttons to commands.

With programs with native LIRC support and without this file, you will generally get only a few working buttons, and that when they can do a lot more. As example, with MPlayer, you can get a list that contains commands that you can use with LIRC:

mplayer -input cmdlist

You can use all the command from this list with LIRC. You just have to add them into ~/.lircrc. It is not necessary to run irexec for applications with native LIRC support.

For the other programs, no button will work and you will have to use irexec.

Before it can do that, however, you will need to create ~/.lircrc and fill it with application specific commands for each button on the remote. Now setup your ~/.lircrc file and you should be able to use LIRC with every applications that supports it. If so, congratulations! Your receiver is working, and you can now start adding support for you remote control. The file follows this format:

File: ~/.lircrc
begin
  prog = ...
  remote = ...
  button = ...
  repeat = ...
  delay = ...
  config = ...
  mode = ...
  flags = ...
end

There is sufficient document concerning the specifics of this file at the LIRC project site.

Some developers have gone through the trouble for you and put together the necessary information for their applications. For example, the tvtime website has a ~/.lircrc file available.

Some example configurations can be found on the french ubuntu forum and in How to configure and use LIRC.

Now run:

irexec

If it generates an error "connection error: Could not connect to the socket" this generally means that one of the LIRC drivers (lirc_dev lirc_gpio or lircd_modulename) isn't loaded properly, or that you permission problems with the lirc device node. First ensure that /etc/init.d/lircd is loaded without errors. Note that this service tends to not stop well, and may need to be zapped then started again. Then ensure that /dev/lirc0 exists and is receiving data as explained above.

Once you have irexec working, you will want to have it start up with each log in. Be sure to use this command to have irexec fork into the background:

irexec --daemon

Setserial

If you are using the serial driver and run into problems on module load, sys-apps/setserial will probably help you.

Install setserial

emerge -a setserial

Enable the serial port

setserial /dev/ttySX uart none

Add setserial to the default runlevel

For setserial to load the module it will need to be added to your startup scripts. First, you need to add a line to /etc/serial.conf:

File: /etc/serial.conf
/dev/ttyS0 uart none
Note: Depending on where you connected your receiver, you might need to specify /dev/ttyS1. If you don't use any other serial devices, you can create two entries and lirc-enable both ttyS0 and ttyS1.

Now you can set it to run at boot:

rc-update add serial boot
.

Alternate startup method

Fix me: Move these instructions to instructions below, merge with hardware specific drivers and Troubleshooting.

Update: You can simply edit /etc/modprobe.d/lirc and add the following line to lirc-enable the port(s) before loading the lirc_serial module:

File: /etc/modprobe.d/lirc
pre-install lirc_serial setserial /dev/ttyS0 uart none

You can also set options for the lirc_serial module there like this:

File: /etc/modprobe.d/lirc
options lirc_serial irq=4 io=0x3f8 type=0 sense=1

Finally run:

update-modules

Using Multiple Devices Simultaneously

The only hardware to natively support multiple blasters on Linux is the CommandIR Mini multi-transceiver. Many other LIRC devices will have both an IR blaster and receiver unified into one - but LIRC may not support this feature (ala lirc_mceusb2). The solution is to get a simple serial IR blaster but this can be difficult to set up via LIRC.

In order to accomplish this, you must make sure that you have compiled support for both devices. Currently the LIRC_DEVICES environment variable only supports doing one device - to work around this change edit your /etc/make.conf:
File: /etc/make.conf
LIRC_DEVICES="all"
After this, make sure you add both lirc_* modules into /etc/modules.autoload.d/kernel-2.6. Additionally, make sure you are used the transmitter USE flag when you emerged lirc.

The second step is to run two concurrent processes of LIRC for both devices and have them interact with each other. This can be tricky so I have taken the liberty of posting my own /etc/init.d/lircd:

File: /etc/init.d/lircd
start() {
	ebegin "Starting lircd"
	start-stop-daemon --start --pidfile /var/run/lircd1.pid --quiet --exec \
       /usr/sbin/lircd -- --driver=default --device=/dev/lirc/1 \ 
       --output=/dev/lircd1 --pidfile=/var/run/lircd1.pid --listen
	start-stop-daemon --start --pidfile /var/run/lircd.pid --quiet --exec \
       /usr/sbin/lircd -- --driver=default --device=/dev/lirc/0 \
       --output=/dev/lircd --pidfile=/var/run/lircd.pid --connect=localhost:8765
	eend $?
}

stop() {
	ebegin "Stopping lircd"
	start-stop-daemon --stop --quiet --pidfile /var/run/lircd1.pid --exec \
        /usr/sbin/lircd -- --pidfile=/var/run/lircd1.pid
	start-stop-daemon --stop --quiet --pidfile /var/run/lircd.pid --exec \
        /usr/sbin/lircd -- --pidfile=/var/run/lircd.pid
	eend $?
}

Essentially what this does is it creates two instances of lircd, one running at /dev/lircd/0 and the other at /dev/lircd/1. Edit the --device=/dev/lirc* line to suit whatever devices you have in your system in whatever order. Since my transmitter is /dev/lirc/1 and my reciever is /dev/lirc/0, /dev/lircd corresponds to my reciever and /dev/lircd1 corresponds to transmitter. This is optimal as some applications may have problems dealing with a non /dev/lircd LIRC device.

Both instances should start when you run:

/etc/init.d/lircd start
Test them out, one by running:
irw
and the other with:
irsend -d /dev/lircd1

Hardware specific instructions

  • iguanaIR
  • UIRT2
  • ATI All-in-Wonder and X10 Remote Controls (atiusb)
  • ATI Remote Wonder II
  • USB-IR-Boy
  • Creative Sound Blaster Audigy 4 (with USB Receiver)
  • Creative Labs Sound Blaster Audigy 2 Platinum
  • Pinnacle PCTV
After following the procedures, if you get: readlink() failed for "/dev/lirc0", maybe you need to do:
ln -sf ttyS0 /dev/lirc0
  • DViCO FusionHDTV DVB-T

CommandIR Mini - USB Multi-Transceiver

CommandIR can control up to four devices independently using emitters and contains a built-in universal receiver to integrate all inbound and outbound IR control into a single Linux-native device. Installation instructions for Gentoo can be found in the manufacturers support site.

ALSA audio

First read about the hardware and the LIRC driver for ALSA. Now you have to tell LIRC what audio device to capture. In order to do it you simply edit the /etc/conf.d/lircd file. Virtually everyone wants to have:
File: /etc/conf.d/lircd
# Options to pass to the lircd process
LIRCD_OPTS="-d hw:0,0"

Note: For the lirc_mceusb2 module you need to have the /etc/conf.d/lircd file this this order! Note 2: -> also notice that i am using /dev/lirc/0 not dev/lirc0 -> the latter did not work for me but the former did.

File: /etc/conf.d/lircd
# Options to pass to the lircd process
LIRCD_OPTS="-d hw:0,0"
LIRCD_OPTS="-d /dev/lirc/0"

Homebrew Serial Receiver (serial)

Serial receiver is smooth sailing, the only tricky thing to know is that kernel support for the serial port will conflict the driver. The way to fix this is to emerge the setserial utility, and then add "setserial /dev/ttyS0 uart none" (ttyS0 is COM1, ttyS1 is COM2, etc.) to /etc/conf.d/local.start. You will then have to add "modprobe lirc_serial" into /etc/conf.d/local.start afterwards because the script is executed after modules.autoload.d.

Alternatively you may try to add "/dev/ttyS0 uart none" to /etc/serial.conf (after emerging setserial) and run serial at boot "rc-update add serial boot". And have lirc_serial module loaded by adding it to /etc/modules.autoload.d/kernel-2.6 (don't forget to run update-modules afterwards).

If you are using receiver wired in "Igor" way, i.e. like the following one - made for "Girder" with "Igor" plugin, make sure to add type=4 option while loading lirc_serial kernel module:

Ircom.png

The whole module loading command may then look like this:

modprobe lirc_serial irq=3 io=0x2f8 type=4

Alternatively you can emerge lirc with serial_igor_cesko module, then putting type=4 in modprobe call is unnecessary.

Enabling software support

Start by adding the lirc USE flag to make.conf. You can then re-emerge your installed packages with remote control support. This will work with:

  • xine-ui
  • MPlayer
  • MythTV
  • Totem
  • Rhythmbox
  • Audacious
  • VLC
  • KDE

and others.

Some packages have LIRC support by default, without the lirc USE flag:

  • Opera

Tips

For multiple remotes you can always concatenate them to one lircd.conf file:

cat remote1_definition.conf remote2_defintion.conf > /etc/lircd.conf

Note that the names for each remote configuration must be different:

File: /etc/lircd.conf
begin remote
  name  Remote1
  ...
end remote

begin remote
  name  Remote2
  ...
end remote

.lircrc configurations for programs including MythTV, Xine, Mplayer, VLC and more can be configured for any remote control and any hardware can be found here.

Troubleshooting

Module does not load

If the kernel modules does not load, there could be a few reasons. If the serial driver in the kernel is being loaded before the LIRC driver, LIRC will fail and complain that the port is already in use.

Code: dmesg output
lirc_dev: IR Remote Control driver registered, at major 61
lirc_serial: port 03f8 already in use
lirc_serial: use 'setserial /dev/ttySX uart none'
lirc_serial: or compile the serial port driver as module and
lirc_serial: make sure this module is loaded first

If this happens you have a couple of options.

Prevent the kernel module from configuring the port

The ideal solution is to run:
echo "/dev/ttySX uart none" >> /etc/serial.conf
This will append the statement "/dev/ttySX uart none" into /etc/serial.conf. After that you have to enable serial init-script via rc-update add serial default. /etc/init.d/serial will disable the uart for the specified ttySX. Now modprobe lirc_serial should work fine during bootup!

Use setserial to de-configure the port

You can follow the instructions and run the setserial /dev/ttySX uart none command, making sure you have already run emerge setserial. You may need to set this up to run at boot so that it can always take effect.

Use modules configuration to load the LIRC module first

If the above does not work as it didn't for me, you could configure the module loading by the following: Modify /etc/modprobe.d/lirc and uncomment the lines that match your serial port, this will enable the lirc_serial module to be loaded before the kernel modules if built or disable the serial port. No init-script for serial is then required.

Load serial support as a kernel module

Still another option is to compile serial support for your kernel as a module, and the Gentoo boot scripts will take care of things for you during boot, but not necessarilly once the system is already up and running. The following may be useful if the /etc/serial.conf update for preventing the kernel from configuring the port doesn't solve the problem.

Tell the serial module that the lirc_driver module (replace lirc_driver with your particular driver, e.g. lirc_sir) is a dependency so that the lirc_driver module captures the I/O port first. Once the lirc_driver is loaded and attached to the port, the regular serial driver takes whatever is left over.

For example, my serial ports use the 8250 module, so the following works:

echo "add below 8250 lirc_sir" >> /etc/modprobe.d/lirc update-modules
Now when I modprobe 8250, the lirc_sir module and all dependencies are loaded first, then everything necessary for the remaining serial ports to function.

Disable serial support in the kernel

Another other option is to disable serial port support in the kernel altogether, as the LIRC driver will take care of things for you. Obviously this will be an impractical solution if you have any other serial devices, but if you don't have any, this will also work.

Device /dev/lirc/0 isn't being created

If LIRC seems to compile, and modprobeing the lirc_<driver> works without errors but you aren't seeing a /dev/lirc/0 being created it is likely because udev is unable to complete the creation of the device. If running:

udevtest /classes/lirc/lirc0

returns an error about udev being unable to read/write from the database becuase there is no such file or directory, re-emerging udev may fix the problem:

emerge --sync emerge udev
Note: please do not run emerge --sync very often, see Upgrading_Packages#Update and etiquette

After the emerge, udev should re-start and /dev/lirc/0 should now show up.

LIRC will not compile

The following flags may become important if LIRC does not work straight as described in the basic configuration.

  • --with-port=port (port number for the lirc device.)
  • --with-irq=irq (irq line for the lirc device.)
  • --with-timer=value (timer value for the parallel driver)
  • --with-tty=file (tty to use (Irman, RemoteMaster, etc.))
  • --without-soft-carrier (if your serial hw generates carrier)
  • --with-transmitter (if you use a transmitter diode)

If any of these options apply to you, you will have to add them with the appropriate values to your LIRC_OPTS variable in /etc/make.conf.

Emerge gives you access violations

There is a bug in gcc that causes problems with sandbox. if the emerge returns you an error of access violation for /usr/src/linux-..../null.gcda Try emerging with the following command:

FEATURES="-sandbox" emerge --ask --verbose lirc

udev-rules

As of the date of this edit (November 11, 2005) there is a minor problem with the default gentoo install of lirc. Emerging LIRC will install a set of udev rules to /etc/udev/rules.d/10-lirc.rules that create the device node /dev/lirc/0. However the file /etc/conf.d/lircd starts the lirc daemon with an option that is not compatible with that udev rule. Accordingly, you may need to edit that files as follows:

File: /etc/conf.d/lirc
# Options to pass to the lircd process
#LIRCD_OPTS="-d /dev/lirc0"
LIRCD_OPTS="-d /dev/lirc/0"

As of the date of this edit (October 28, 2009) the ebuild won't install udev specific rules if there is no module to load (as far as i know for "lirc_devices_asusdh") so here is what i did. First, get the info from the command line udevadm:

udevadm info --attribute-walk --name=/dev/usb/hiddevX

Where "X" is your device number, see dmesg. What you need to get is:

ATTRS{idVendor}=="xxxx"
ATTRS{idProduct}=="xxxx"

Now, add this rules:

File: /etc/udev/rules.d/20-lircd.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="xxxx", SYMLINK+="the_name_you_want"

Finnaly, edit the file /etc/conf.d/lircd as follows:

File: /etc/conf.d/lircd
 
Options to pass to the lircd process

# for devices with lirc-kernel-module
#LIRCD_OPTS="-d /dev/lirc0"
LIRCD_OPTS="--device=/dev/the_name_you_want"

See Also