RF remote with Fedora 10
Remote controls for PCs are really great. With an ordinary remote for just a few bucks you can control almost everything on your PC while sitting on your couch. Well, thanks to lirc, of course. But most of them have one major design flaw: They’re infrared based, i.e. remote controls transmit data on an modulated infrared beam to your IR-receiver. Even a (think) sheet of paper can block the beam. So your remote always has to be within visual range of your receiver.
But there are some remotes out there which use a 433MHz beam instead of the short-waved IR-beam. For example this one by X10
Installing lirc is really no big deal
yum install lirc
It’s as simple as that!
You may want to tell Fedora to start the daemon automatically
chkconfig lirc on
You have to tell lirc which receiver you are using. Change the value for LIRC_DRIVER in /etc/sysconfig/lirc to atilibusb:
[...] # The infrared receiver (and/or transmitter) driver to be used by lircd(8), # similar to passing "-H driver" to lircd(8). # Run "/usr/sbin/lircd -H help" to get a listing of supported drivers. LIRC_DRIVER="atilibusb" [...]
There a basically two ways of configuring your remote control: You can use one of the config files in /usr/share/lirc-remotes/ that come with lirc or create your own with a small program called irrecord
# /etc/init.d/lirc stop # irrecord -H atilibusb ~/lircd.conf
The instructions are quite self-explaining. You may want to backup your original lircd.conf before replacing it with the one generated by irrecord
# mv /etc/lircd.conf /etc/lircd.conf.orig # cp ~/lircd.conf /etc/lircd.conf # /etc/init.d/lirc restart
You can check if your configuration is working fine with irw. You should be able to see output for every configured button on you remote
$ irw 00000014709b0000 00 world x10 00000014709b0000 01 world x10 [...]
Now that the remote is completely configured, you can start telling your applications which action to perform when a certain button is pressed. Every (lirc supporting) application scans ~/.lircrc (or a similar config file, e.g. MythTV uses ~/.mythtv/lircrc) and has some predefined functions you can use.
You may want to split the ~/.lircrc-file per application
## MythTV include ~/.lirc/mythtv ## MediaKeys include ~/.lirc/mediakeys [...]
Now you can create an new folder ~/.lirc and place a seperate config-file for every application in it
$ mkdir ~/.lirc $ touch ~/.lirc/mythtv
Don’t forget to add a new include statement in ~/.lircrc for every new file in ~/.lirc
The stucture within ~/.lirc/[appname] is quite simple. A short excerpt from my ~/.lirc/mythtv:
[...] begin prog = mythtv button = ok config = Space end begin prog = mythtv button = up config = Up end [...]
Every button has to be surrounded by one begin– and one end-statement. You have to specify the program that listens to this configuration in the prog-statement. The values for button matches the values you configured in /etc/lirc and with the config-statement you can map every button on your remote to one of the predefined functions of you application (all functions you can use in MythTV can be found in the MythTV-Wiki).
Using you multimedia keys with lirc is a little more complicated. Let’s have a look at the config file ~/.lirc/mediakeys first (don’t forget to add the include-statement to ~/.lircrc !):
### MediaKeys begin prog = irexec button = volume+ repeat = 1 delay = 5 config = echo KeyStrPress XF86AudioRaiseVolume KeyStrRelease XF86AudioRaiseVolume | xmacroplay $DISPLAY end begin prog = irexec button = volume- repeat = 1 delay = 5 config = echo KeyStrPress XF86AudioLowerVolume KeyStrRelease XF86AudioLowerVolume | xmacroplay $DISPLAY end begin prog = irexec button = mute repeat = 0 config = echo KeyStrPress XF86AudioMute KeyStrRelease XF86AudioMute | xmacroplay $DISPLAY end begin prog = irexec button = play config = echo KeyStrPress XF86AudioPlay KeyStrRelease XF86AudioPlay | xmacroplay $DISPLAY end begin prog = irexec button = pause config = echo KeyStrPress XF86AudioPause KeyStrRelease XF86AudioPause | xmacroplay $DISPLAY end begin prog = irexec button = next config = echo KeyStrPress XF86AudioNext KeyStrRelease XF86AudioNext | xmacroplay $DISPLAY end begin prog = irexec button = previous config = echo KeyStrPress XF86AudioPrev KeyStrRelease XF86AudioPrev | xmacroplay $DISPLAY end
irexec is a small program that listens to incoming lirc-events and starts the program you configured within the config-statement. To emulate that a multimedia key on your keyboard is pressed you can use xmacroplay. Unfortunately there is no xmacro-rpm-package available in the Fedora-repository. But you can find one in Nathan Wood’s Pan-Galactic Memory Bank (mirrored here: i386, x86_64, source rpm).
For testing your multimedia key configuration you simply start irexec without any options:
You may want to start irexec automatically when you log in to your system. Adding irexec as daemon to gnome autostart is one way of doing it (of course, if you use kde this looks a little different…). Create a new file called irexec.desktop
$ touch ~/.config/autostart/irexec.desktop
with the following content:
[Desktop Entry] Type=Application Name=irexec Exec=/usr/bin/irexec -d Icon=system-run Comment= Name[en_US]=irexec Comment[en_US]= X-GNOME-Autostart-enabled=true
Actually you don’t need lirc to use this RF receiver from X10:
# lsusb [...] Bus 002 Device 002: ID 0bc7:0006 X10 Wireless Technology, Inc. Wireless Transceiver (ACPI-compliant) [...]
There already is a native kernel module called ati_remote which can talk to the receiver. Now why am I telling you this after you went through the whole lirc configuration? Easy: It doesn’t support every key on every remote and you cannot change the keymappings manually, so lirc is definitly the more flexible choice (Christoph Langner’s Blog (german!)).
But it could be, that ati_remote comes as kernel module with you distribution as it does with Fedora 10. Every time you plugin your receiver, the kernel will automatically load the ati_remote module which heavily interferes with lirc. So if you’re facing unexpected output from irrecord (or even no output at all) you should probably unload the module:
To prohibit the kernel from loading the module again, you can blacklist it by adding ‘blacklist ati_remote’ to your modprobe configuration:
echo blacklist ati_remote >> /etc/modprobe.d/blacklist