lircd

LIRC daemon - decodes infrared signals and provides them on a Unix domain socket

  lircd [-n | --nodaemon] [-pmode |
  --permission=mode] [-ddevice |
  --device=device] [-l[port] |
  --listen[=port]] [-chost:[port] ... |
  --connect=host[:port] ...] [config_file]
lircd -h | --help
  lircd -v | --version

The main task of lircd is to decode the infrared signals and provide an uniform interface for client applications. Clients can connect to lircd through a Unix domain socket which is located in /dev/lircd. Using this socket they will get the infrared codes received by lircd and they can send commands to lircd.

If you provide the --nodaemon option lircd won't fork to background.

The --permission option gives the file permission of /dev/lircd if it has to be created in octal representation. Read the documentation for chmod for further details. If no --permission option is given when the socket is initially created the default is to give all users read and write permissions (0666 in octal representation). If /dev/lircd already exists this option has no effect.

With the --device option you can select the character device which lircd should read from. The default currently is /dev/lirc but it probably will change in future.

With the --listen option you can let lircd listen for network connections on the given port. The default port is 8765. No sequirity checks are currently implemented.

The --connect option allows you to connect to other lircd servers that provide a network socket at the given host and port number. The number of such connections is currently limited to 100.

The config file for lircd is located in /usr/local/etc/lircd.conf. lircd has its own log file in /var/log/lircd (beginning with LIRC version 0.6.1 you can configure lircd to use syslogd for log messages; then it depends on your system configuration where log messages will show up). You can make lircd reread its config file and reopen its log file by sending the HUP signal to the program. That way you can rotate old log files.

Read also the daemon note.

lircmd

LIRC mouse daemon - translates infrared signals into mouse events

  lircmd [-n | --nodaemon] [config_file]
  lircmd -h | --help
  lircmd -v | --version

This daemon can simulate a MouseSystems or IMPS/2 type mouse. It gets the received buttons from lircd and converts them to mouse events. To make this possible, lircmd needs a config file located in /usr/local/etc/lircmd.conf. In this file you have to determine which button from which remote causes a mouse move or a mouse button click.

If you provide the --nodaemon option lircmd won't fork to background.

lircmd will use syslogd to output error messages. It depends on your system configuration where they will show up.

Read also the daemon note.

lircd and lircmd are daemons. You should start them in some init script depending on your system. There are some example scripts for different distributions in the contrib directory. lircmd has to be started after lircd as it connects to the socket lircd provides.

If you start lircd or lircmd from your shell prompt you will usually get back immediately to the prompt. Often people think that the program has died. But this is not an error. lircd and lircmd are daemons. Daemons always run in background.

irexec

irexec - run programs with one button press

  irexec [-d | --daemon] [config_file]
  irexec -h | --help
  irexec -v | --version

This program lets you execute arbitrary commands on an IR signal decoded by lircd, the LIRC daemon. You can give irexec a command line parameter which has to be a name of a valid config file. If no command line parameters are given irexec reads the default config file which is usually ~/.lircrc. If you add the --daemon option irexec will fork to background. That way you can easily start irexec from an init script. In this case you should specify a config file on the command line as irexec won't be able to find your home directory. Potential uses are shuting down the computer, starting a dial-up connection etc.

If irexec executes a program it will wait until this program terminates. So append a '&' to the command string if you don't want that.

The config string consists of the command to be run.

Note: If you start irexec, it reads your ~/.lircrc and reacts only on prog= entries that point to irexec. If you have included more than one program in your .lircrc, then start all these programs, they react itself only to their according entries in .lircrc.

irpty

irpty - pseudo tty driver

  irpty [-s socket_name] [-e] [-i] [-n] [-v] config_file -- program [args ...]

irpty connects to lircd to receive infrared codes and converts them to key strokes. E.g. type irpty ~/.lircrc -- workbone to control the CD-player program workbone. Of course you will have to create an appropriate config file for this purpose first. The config string will be passed to the desired application. Note that you can use escape sequences to specify non printable characters. Have a look at the .lircrc file format description for details.

irpty accepts the following options:

-s socket_name

select a non-default socket location

-e

disable echo

-i

ingore EOF

-n

force non-interactive mode

-v

verbose mode

irxevent

irxevent - infrared X-event sender

  irxevent [config_file]

by Heinrich Langos <heinrich@mad.scientist.com>

Irxevent is a program that I wrote to send button clicks and key presses to X applications triggered by a LIRC driven remote control. You can control your favorite CD/MP3 player or your TV tuner program or any other X application that responds to keyboard or mouse input. If you like to you can send emacs ^X^S from your armchair.

Irxevent is a complement to irexec and irpty and works with the same config file. (~/.lircrc) For a complete sample-.lircrc look at examples/lircrc.

Part of your .lircrc could look like this:

begin
        prog = irxevent
        button = VIDEO_UP    
        config = Key SHIFT-KP_Add CurrentWindow
end
begin
        prog = irxevent
        button = VIDEO_DOWN
        config = Key SHIFT-KP_Subtract CurrentWindow
end
begin
        prog = irxevent
        button = STOP
        config = Key ctrl-c CurrentWindow
end
begin
        prog = irxevent
        button = 0
        config = Key f xawtv
        config = Key f xawtv
end
begin
        prog = irxevent
        button = POWER
        config = Key q xawtv
end
begin
        prog = irxevent
        button = CH_DOWN
        config = Button 1 329 92 kscd
end
begin
        prog = irxevent
        button = UP
        config = Button 1 110 80 GQmpeg
end
begin
        prog = irxevent
        button = DOWN
        config = Button 1 130 80 GQmpeg
end

Simply said config = lines may look like this:

config = Key [shift-][ctrl-][alt-]<key> <windowname> | CurrentWindow
config = Button <button> <x> <y> <windowname> | CurrentWindow
config = xy_Key <x> <y> [shift-][ctrl-][alt-] <key><windowname> | CurrentWindow

some more examples:

config = Key Up xawtv
config = Key Down xawtv
config = Button 1 50 110 xclickme
config = Key q xawtv
config = Key ctrl-c mpg123
config = Key shift-Page_Up rxvt

In BNF this looks like:

LINE    = "config =" <KEY|BUTTON|XYKEY> <TARGET>
XYKEY   = "xy_Key" <x_position> <y_position> <MOD>Keyname
KEY     = "Key" <MOD>Keyname
MOD     = ["shift-"]["numlock-"]["ctrl-"]["alt-"]["meta-"]
          ["numlock-"]["mod3-"]["mod4-"]["scrlock-"]
BUTTON  = "Button" <1..5> <x_position> <y_position>
TARGET  = Windowname | "CurrentWindow"

Keyname

is the key symbol that is declared in X windows. E.g. "Up" refers to the cursor arrow pointing up. "KP_Add" is the plus sign on the key pad. Just take a look at irxevent.keys if you are not sure about a symbol's name.

Windowname

can be the first characters of the window name displayed by the window manager or the name that is displayed below the icon. Some programs use the name displayed by the window manager to show a lot of status information but don't change the icon name (like xawtv). Others append information to the window name ("GQmpeg - kill_windooz.mp3"). If neither window name nor icon name match the given Windowname information from XClassHint(3x) will be checked.

CurrentWindow

refers to the active window as returned by XGetInputFocus(3x). Most times this is the window with your mouse pointer in it.

If you have problems finding the coordinates for a button click you can try xev -id <window_id>. The window_id can be found using xwininfo. If xev and xwininfo are not part of your distribution you can find them at a FTP server using the search engine at: http://ftpsearch.ntnu.no/. xev also reports the names of key symbols like "Control_L" (your left control key) or "KP_Subtract" (the 'minus' key on your keypad).

There are programs that do not accept any synthetic X-events by default because they can cause security problems. Currently xterm and xemacs are known to ignore events simulated by irxevent.

You can however make xterm accept external events by enabling "Allow SendEvents" in the "Main Options" (hold down the Ctrl button and press the left mouse button inside the xterm window). You can as well place this line into your .Xresources file to change this permanently:

  XTerm.vt100.allowSendEvents:    true

  xterm -xrm "XTerm.vt100.allowSendEvents:    true"

`x-allow-sendevents' is a built-in boolean variable.

Value: t

Documentation:
*Non-nil means to allow synthetic events.  Nil means they are ignored.
Beware: allowing emacs to process SendEvents opens a big security hole.

  (setq x-allow-sendevents t)

If you have problems sending events please drop me an email.

irrecord

irrecord - application for recording IR-codes for usage with LIRC

  irrecord [-ddevice | --device=device]
           [-f | --force] file
  irrecord -h | --help
  irrecord -v | --version

This program will record the signals from your remote control and create a config file for lircd. A proper config file for lircd is maybe the most vital part of this package, so you should invest some time to create a working config file. Although I put a good deal of effort in this program it is often not possible to automatically recognize all features of a remote control. Further information on this topic is available in this section.

If the program fails to recognize the protocol of the remote control you should use the --force option to at least create a config file in raw mode.

If file already exists and contains a valid config irrecord will use the protocol description found there and will only try to record the buttons. This is very useful if you want to learn a remote where config files of the same brand are already available. Of course this will only work if the remotes use the same protocol but it's worth a try. You will find template files for the most common protocols in the remotes/generic/ directory of this package. The name of the new file is created by appending .conf to the given filename in this case.

This program is provided to you free of charge. So it'd be only fair to respect its license.

irw

irw - sends data from Unix domain socket to stdout

  irw [socket_name]

irw will connect to any Unix domain socket and will print the data that it receives to stdout. If you don't give it a socket name argument it will watch /dev/lircd. Useful for debugging.

mode2, smode2, xmode2

mode2, smode2, xmode2 - shows the pulse/space length of infrared signals

  mode2 [-ddevice | --device=device]
  mode2 -h | --help
  mode2 -v | --version

  smode2 [-ddevice | --device=device]
         [-tms/unit | --timediv=ms/unit]
  smode2 -h | --help
  smode2 -v | --version

  xmode2 [-ddevice | --device=device]
         [-tms/unit | --timediv=ms/unit] [-m | --mode]
  xmode2 -h | --help
  xmode2 -v | --version

The main purpose of these programs is to check operation of your home-brew LIRC receiver hardware and to see the IR waveform of the remote controller without an expensive oscilloscope. Very useful for debugging. Of course this program won't work with hardware that decodes the signals itself like e.g. TV cards or the Irman.

mode2 will simply print pulse&space lengths to stdout.

smode2 uses the svgalib to show the IR waveform in a graphical representation. The time division is variable from 1 ms/unit to extremely high values (integer type) but there is no point increasing this value above 20 ms/unit, because one pulse is about 1 ms. This kind of presentation is much more exciting than the simple pulse&space output showed by mode2.

xmode2 is based on smode2 by Sinkovics Zoltan. It is just a conversion from svga to X with some basic support for resizing. The only differnance is that the --mode option enables an alternative display mode.