https://wiki.archlinux.org/api.php?action=feedcontributions&user=Pajaro&feedformat=atomArchWiki - User contributions [en]2024-03-29T01:53:53ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:LIRC&diff=242799Talk:LIRC2013-01-03T08:29:01Z<p>Pajaro: </p>
<hr />
<div>* should try if editing /etc/rc.d/lircd with "lircd --device=/dev/ttyS1 --driver=creative -p 0666" is a better solution instead of compiling lirc module for ttyS1<br />
<br />
* It would probably be better to treat the remote as a HID with devinput than to force 'lirc' mode in /sys/class/rc. [[User:TheCycoONE|TheCycoONE]] 20:18, 26 May 2011 (EDT)<br />
<br />
* Apoulos, I made your section point to the related ArchLinux bug. There there is an explanation of how to find a generic workaround for the problem with lirc.service.</div>Pajarohttps://wiki.archlinux.org/index.php?title=LIRC&diff=242798LIRC2013-01-03T08:26:21Z<p>Pajaro: </p>
<hr />
<div>[[Category:Other hardware]]<br />
[[Category:Audio/Video]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers using LIRC with serial or USB infrared devices.}}<br />
{{Article summary end}}<br />
<br />
[http://lirc.org/ LIRC] stands for "Linux Infrared Remote Control", a program to use infrared devices (like your remote control from your TV) with linux.<br />
<br />
==Supported hardware==<br />
<br />
First of all, check the [http://lirc.org/html/table.html official list of supported hardware]. Check the table to know, which LIRC kernel modules and lircd driver required for your infrared receiver.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] the {{Pkg|lirc-utils}} package, which is available in the [[Official Repositories|official repositories]].<br />
<br />
The most of LIRC kernel drivers are already included in the mainline kernel. You need to install {{Pkg|lirc}} package only, if your hardware requires lirc_atiusb, lirc_i2c or lirc_wpc8769l modules.<br />
<br />
==Serial receivers==<br />
<br />
===Serial receivers that depend on lirc_serial===<br />
<br />
Make sure that your serial port is activated in the BIOS. There you can also set and lookup I/O address and IRQ settings of your ports.<br />
<br />
Now there might be a problem: the module lirc_serial is build to use ttyS0 (COM1), if your device is not connected to ttyS0, you will have to either change the module-options or [[LIRC#Building_the_LIRC_serial_module_for_another_ttySx|rebuild the LIRC module]]. If your device is connected to ttyS0, you can [[LIRC#Loading|skip this step]]<br />
<br />
To change the options for the lirc_serial module, you edit {{ic|/etc/modprobe.d/modprobe.conf}} and add this line:<br />
<br />
options lirc_serial io=0x2f8 irq=3<br />
<br />
You should change the values after io and irq to reflect you serial port settings, the values above may work for you if you are using ttyS1 (COM2) to connect your IR-device. But you will find the correct values by checking dmesg:<br />
<br />
$ dmesg | grep ttyS<br />
<br />
===Other serial receivers===<br />
<br />
See [[LIRC#Other_receivers]]<br />
<br />
===Building the lirc_serial module for another ttySx===<br />
<br />
Update abs<br />
<br />
# abs<br />
<br />
Copy the LIRC files to a directory you choose yourself:<br />
<br />
$ cp /var/abs/extra/system/lirc /some/dir<br />
<br />
$ cd /some/dir<br />
<br />
Edit the PKGBUILD in that directory.<br />
<br />
Replace the line:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=all \\<br />
return 1[/code]<br />
<br />
with:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=com2 \<br />
|| return 1[/code]<br />
<br />
Where you replace com2 with the com-port you need.<br />
<br />
Build and install the package:<br />
<br />
$ makepkg<br />
# pacman -U lirc-version.pkg.tar.gz<br />
<br />
===Loading===<br />
<br />
Now try to load the serial module:<br />
<br />
# modprobe lirc_serial<br />
<br />
If this produces an error which says your serial port is not ready, you have the problem that your serial port support is build into the kernel and not as a module (in the default arch kernel it is build into the kernel)<br />
<br />
If it is built into the kernel you will have to do the following (remember that it is built into the kernel, you will need to make some changes later too)<br />
<br />
You will have to release the serial port:<br />
<br />
# setserial /dev/ttySx uart none<br />
<br />
(Replace x with your port number)<br />
<br />
Load the module again:<br />
<br />
# modprobe lirc_serial<br />
<br />
Now it should not show any errors, and the modules lirc_serial should be listed in lsmod<br />
<br />
==USB receivers including most onboard devices==<br />
This outlines the general procedure, the mceusb module which is used by many devices is used as an example.<br />
<br />
# modprobe mceusb<br />
<br />
Start the LIRC daemon:<br />
<br />
$ /etc/rc.d/lircd start<br />
<br />
Test it with irw, it will output the commands received by the IR receiver that match your {{ic|lircd.conf}} file. So start irw, point your remote and start pressing buttons. <br />
<br />
$ irw<br />
000000037ff07bfe 00 One mceusb<br />
000000037ff07bfd 00 Two mceusb<br />
000000037ff07bfd 01 Two mceusb<br />
000000037ff07bf2 00 Home mceusb<br />
000000037ff07bf2 01 Home mceusb<br />
<br />
The above procedure however has been simplified and may not work that easily. One of the reasons the lircd daemon may not be working is because it expects to be run at startup and needs root permissions because it will create device nodes in {{ic|/dev}}. Try "man lircd" for more information.<br />
<br />
Continue with [[#Making a configuration file]]<br />
<br />
=== Setup a HID device with LIRC ===<br />
Some remotes are supported in the kernel where they are treated as a keyboard and mouse. Every button on the device is recognized as keyboard or mouse events which can be used even without LIRC. LIRC can still be used with these devices to gain greater control over the events raised and integrate with programs that expect a LIRC remote rather than a keyboard. As drivers are migrated to the kernel, devices which use to only be useable through LIRC with their own {{ic|lirc.conf}} files become standard HID devices.<br />
<br />
Some HID remotes actually simulate a USB infrared keyboard and mouse. These remotes show up as two devices so you need to add two LIRC devices to {{ic|lircd.conf}}.<br />
<br />
First we need the {{ic|/dev/input}} device for our remote:<br />
<br />
$ ls /sys/class/rc/rc0<br />
<br />
One of the files should be input''#'', where the number matches the event''#'' of the device. (To clarify you can check that directory, it will have an event''#'' file.<br />
<br />
{{Note|If you have more than one ir device then there may be multiple directories under {{ic|/sys/class/rc}}. Under event''#'' {{ic|cat name}} to verify which device you are looking at.}}<br />
<br />
then go to {{ic|/dev/input/by-id}}<br />
<br />
$ ls -l /dev/input/by-id<br />
<br />
You should find a file that symlinks to the input''#'' above, and possibly others with a similar names for mouse events.<br />
<br />
lrwxrwxrwx 1 root root 9 10月 14 06:43 usb-3353_3713-event-if00 -> ../event9<br />
lrwxrwxrwx 1 root root 10 10月 14 06:43 usb-3353_3713-event-if01 -> ../event10<br />
<br />
Here 'usb-3353_3713-event-if00' and 'usb-3353_3713-event-if01' are the Linux input device event for our HID device, one for the keyboard, another for the mouse.<br />
<br />
Then, we need to edit {{ic|/etc/conf.d/lircd.conf}}. This file contains the parameters for LIRC daemon<br />
<br />
#<br />
#Parameters for daemon<br />
#<br />
<br />
LIRC_DEVICE="/dev/input/by-id/usb-3353_3713-event-if00"<br />
LIRC_DRIVER="devinput"<br />
LIRC_EXTRAOPS=""<br />
LIRC_CONFIGFILE="/etc/lirc/lircd.conf"<br />
<br />
{{Note|Here we set up a LIRC device with the id 3353_3713, you should replace it with your own device input event name, whatever it is.}}<br />
<br />
The latest version of the config file for HID remotes exists in the LIRC git repository [http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=blob_plain;f=remotes/devinput/lircd.conf.devinput;hb=HEAD]. Simply save it as {{ic|/etc/lirc/lircd.conf}}.<br />
<br />
In order to launch the LIRC daemon for HID remote, You must enable evdev module first<br />
# modprobe evdev<br />
<br />
{{Note|LIRC 0.8.6 has changed the default socket location from {{ic|/dev/lircd}} to {{ic|/var/run/lirc/lircd}}, but many applications still look for the socket in the old location. Since lirc-utils 0.8.6-3 the {{ic|/etc/rc.d/lircd}} script creates a symlink from {{ic|/dev/lircd}} to the {{ic|/var/run/lirc/lircd}} socket when it starts the lircd daemon and removes the link when the daemon is stopped.}}<br />
<br />
==Other receivers==<br />
<br />
There are many receivers that do not need any kernel module at all. This applies to any type of receiver, including serial receivers and usb receivers. Check the next link to see what kernel modules you need to load, if any:<br />
<br />
[http://www.lirc.org/html/table.html LIRC supported devices]<br />
<br />
==Checking module based receivers==<br />
<br />
''NOTE: This section only applies if your device requires a lirc_[driver] kernel module.''<br />
<br />
Before you start using lirc, you should check if your receiver is working, and if there is IR interference. Possible sources of interference include monitors/televisions (especially plasma displays), fluorescent lamps and direct or ambient sunlight. Start the following command to display raw receiver input.<br />
<br />
# mode2 -d /dev/lirc0 <br />
<br />
If you press buttons on any IR remote, you should see a series of pulses and spaces. If there is very frequent output without pressing buttons on your remote, your receiver suffers from interference. You want to avoid such interference, e.g. by placing the receiver behind or under your plasma tv.<br />
<br />
If you can't make out where the interference is coming from, you can try to put a cardboard roll right in front of the receiving diode, so that it only gets light from a specific direction. Invoke mode2 as above. Then point at different locations till you receive IR noise.<br />
<br />
==LIRC daemon configuration==<br />
<br />
The lircd configuration lives under /etc/conf.d/lircd.conf, and it is all you need to setup your device if it does not require any special kernel module.<br />
<br />
{{Box|IMPORTANT:|lirc-utils package on ArchLinux has a bug. You will have to create your own systemd unit or find another workaround. See [https://bugs.archlinux.org/task/31890 bug#31890] |#DF0000|#FFDFDF}}<br />
<br />
==Making a configuration file==<br />
<br />
You need a configuration file for your remote control copied or symlinked to {{ic|/etc/lirc/lircd.conf}}. A number of devices have already been included with the lirc package, they can be found in {{ic|/usr/share/lirc/remotes}}. If your specific device is not included, the LIRC site offers configuration files for a large number of extra [http://lirc.sourceforge.net/remotes/ devices].<br />
<br />
If your device does not already have a config file, you can create it yourself with the following command. You should avoid interference (see above) while creating the config file. <br />
<br />
# irrecord -d /dev/lirc0 /tmp/my_remote<br />
<br />
Just follow the instructions. To get a list of valid button names, refer to the output of<br />
# irrecord --list-namespace<br />
The resulting file, {{ic|/tmp/my_remote}}, should then be copied to {{ic|/etc/lirc/lircd.conf}}. If you want to use several remotes, you repeat the irrecord step with each remote and different filenames, and then concatenate all the resulting files into {{ic|/etc/lirc/lircd.conf}}:<br />
<br />
# cat /tmp/my_remote /tmp/my_remote2 /tmp/my_remote3 > /etc/lirc/lircd.conf<br />
<br />
{{Note|As of lirc-0.8.6 the default location of lircd, lircmd and lircrcd config files was moved to {{ic|/etc/lirc/lircd.conf}}, {{ic|/etc/lirc/lircmd.conf}} and {{ic|/etc/lirc/lircrc}}. If the config files are not found in that location, they are still searched at the old location in {{ic|/etc/.}}}}<br />
<br />
===Testing===<br />
<br />
First start the lircd daemon:<br />
<br />
# /etc/rc.d/lircd start<br />
<br />
A good way to see if LIRC is running is to run irw.<br />
<br />
$ irw<br />
<br />
When you press a button, you should see something like this:<br />
<br />
0000000000000001 00 play sony2<br />
0000000000000001 01 play sony2<br />
0000000000000001 02 play sony2<br />
0000000000000001 03 play sony2<br />
<br />
In this case the remote is called sony2, the button is called play, and LIRC has seen it 4 times.<br />
<br />
==Run LIRC at bootup==<br />
<br />
Remember if you had to execute the setserial command while [[LIRC#Loading|loading]] the module?<br />
<br />
If so, [[LIRC#Your serial port support is compiled into the kernel|your serial port support is compiled into the kernel]]<br />
<br />
===Your serial port support is compiled as a module in the kernel===<br />
<br />
This is rather easy: you will just have to add lirc_serial to the modules list and lircd to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
===Your serial port support is compiled into the kernel===<br />
<br />
This is more complicated, you cannot just add the lirc_serial to the modules list in {{ic|/etc/rc.conf}}, as the serial port should be released first.<br />
<br />
So I created a custom startup script to fix this problem.<br />
<br />
{{hc|/etc/rc.d/start_lirc|<nowiki><br />
#!/bin/bash<br />
#/etc/rc.d/start_lirc<br />
#releases ttySx and loads lirc_serial module<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy "release ttySx"<br />
setserial /dev/ttySx uart none<br />
#load lirc module<br />
modprobe lirc_serial<br />
stat_done<br />
;;<br />
stop)<br />
stat_busy "unload lirc module"<br />
rmmod lirc_serial<br />
stat_done<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now load the daemons: add "start_lirc" and "lircd" to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
==Program specific configuration==<br />
<br />
===Generate your own lircrc with Mythbuntu's lircrc-generator===<br />
<br />
'''mythbuntu-lircrc-generator''' is intended to be started from a system with LIRC installed. It requires that you choose a remote via the LIRC package or have a {{ic|lircd.conf}} handy prior to running. It will then produce a sane {{ic|.lircrc}} for the current user.<br />
<br />
[https://aur.archlinux.org/packages.php?ID=33849 Mythbuntu's Lirc/Lircrc Generator is available on AUR]<br/><br />
[http://manpages.ubuntu.com/manpages/intrepid/man1/mythbuntu-lirc-generator.1.html Man page]<br />
<br />
===Enable LIRC support in xine===<br />
<br />
Now LIRC works, but you have no program that can communicate with LIRC. This section will explain how to make xine work, but you can use xmms and mplayer (and probably a lot of other programs too) to work with LIRC.<br />
<br />
====Compile xine with LIRC support====<br />
Download the xine-ui PKGBUILD with [https://wiki.archlinux.org/index.php/Arch_Build_System ABS].<br />
<br />
Add " --enable-lirc" to the {{ic|./configure}} line<br />
<br />
Compile:<br />
<br />
$ makepkg<br />
<br />
Uninstall old xine-ui and install the new one<br />
<br />
# pacman -R xine-ui<br />
# pacman -U xine-filename.pkg.tar.gz<br />
<br />
====Configure xine to use LIRC====<br />
<br />
Let xine produce a default {{ic|.lircrc}} file. In your home directory, type:<br />
<br />
$ xine --keymap=lirc>.lircrc<br />
<br />
Now, in order to have a functioning xine+lirc, edit the {{ic|.lircrc}} file to your preferences.<br />
<br />
However, you may choose to configure LIRC to control more than just xine. If this is the case, you will need to manually edit the {{ic|.lircrc}} file, and add elements. <br />
<br />
Xine-ui<br />
Mplayer<br />
Totem<br />
Vlc<br />
Rhythmbox <br />
<br />
All work with LIRC, but you must enable LIRC support in the program in some cases, such as VLC. Simply copy the vlc packagebuild and edit it so that "--enable-lirc" is one of the compile options for VLC not FFMPEG!<br />
<br />
===Configure Amarok2 to use LIRC===<br />
<br />
Depending on your controller model, the following configuration works with Amarok2-svn. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##amarok2<br />
<br />
begin<br />
button = Play<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Play<br />
end<br />
<br />
begin<br />
button = Pause<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Pause<br />
end<br />
<br />
begin<br />
button = Stop<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Stop<br />
end<br />
<br />
begin<br />
button = Skip<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Next<br />
end<br />
<br />
begin<br />
button = Replay<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Prev<br />
end}}<br />
<br />
===Configure Audacious(2) to use LIRC===<br />
Depending on your controller model, the following configuration works with all versions of Audacious, including the mercurial builds. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##audacious<br />
<br />
begin<br />
prog = audacious<br />
button = Play<br />
config = PLAY<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Pause<br />
config = PAUSE<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Stop<br />
config = STOP<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Skip<br />
config = NEXT<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Replay<br />
config = PREV<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolUp<br />
config = VOL_UP<br />
repeat = 1<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolDown<br />
config = VOL_DOWN<br />
repeat = 1<br />
end}}<br />
<br />
Additionally, there are other values that may be set according to the model set forth above. This was taken from the lirc.c file from audacious-plugins source code:<br />
<br />
{{hc|lirc.c|PLAY<br />
STOP<br />
PAUSE<br />
PLAYPAUSE<br />
NEXT<br />
PREV<br />
SHUFFLE<br />
REPEAT<br />
FWD<br />
BWD<br />
VOL_UP<br />
VOL_DOWN<br />
QUIT<br />
MUTE<br />
BAL_LEFT<br />
BAL_RIGHT<br />
BAL_CENTER<br />
LIST<br />
PLAYLIST_CLEAR<br />
PLAYLIST_ADD}}<br />
<br />
===Configure Mplayer to use LIRC===<br />
<br />
{{hc|~/.lircrc|2=##mplayer<br />
<br />
begin<br />
button = PLAY/PAUSE<br />
prog = mplayer<br />
config = pause<br />
repeat = 1<br />
end<br />
begin<br />
button = FWD<br />
prog = mplayer<br />
config = seek 5<br />
end<br />
begin<br />
button = REV<br />
prog = mplayer<br />
config = seek -5<br />
end<br />
begin<br />
button = MAXIMIZE<br />
prog = mplayer<br />
config = vo_fullscreen<br />
end<br />
}}<br />
<br />
only change PLAY/PAUSE, FWD etc. on keys from your /etc/lircd.conf<br />
<br />
==Device Specific Examples==<br />
=== X10 ===<br />
There is a dedicated wiki page with information about [[X10]]<br />
<br />
===Asus DH Deluxe series motherboard===<br />
Check the output of:<br />
{{bc|$ cat /dev/usb/hiddevX}}<br />
<br />
where X is 0,1 or bigger, and press some buttons on remote.<br />
If you can see reply, device works fine, follow steps:<br><br />
<br />
1. In file {{ic|/etc/conf.d/lircd.conf}} add:<br><br />
{{bc|1=LIRC_DRIVER="dvico"}}<br />
2. Reload LIRC: <br />
{{bc|/etc/rc.d/lircd restart}}<br />
<br />
===ASRock ION series (Nuvoton) quickstart===<br />
<br />
$ ln -s /usr/share/lirc/remotes/lirc_wb677/lircd.conf.wb677 /etc/lirc/lircd.conf<br />
$ /etc/rc.d/lircd restart<br />
<br />
===Streamzap PC Remote (USB)===<br />
{{Note|Xorg now auto recognizes this remote as a keybaord!}} <br />
To disable this behavior, add the following to {{ic|/etc/X11/xorg.conf.d/90-streamzap.conf}}:<br />
{{bc|Section "InputClass"<br />
Identifier "Ignore Streamzap IR"<br />
MatchProduct "Streamzap"<br />
MatchIsKeyboard "true"<br />
Option "Ignore" "true"<br />
EndSection}}<br />
<br />
#Install both packages (lirc lirc-utils)<br />
#Modprobe both kernel mods (lirc_dev and streamzap) (add these to your MODULES array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Create your {{ic|/etc/lirc/lircd.conf}} (for this remote, copy {{ic|/usr/share/lirc/remotes/streamzap/lircd.conf.streamzap}} to {{ic|/etc/lirc/lircd.conf}})<br />
#Start lircd via /etc/rc.d/lircd start (add lircd to your DAEMONS array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Test the remote/lirc with irw<br />
<br />
$ irw<br />
00000000000028cc 00 CH_UP Streamzap_PC_Remote<br />
00000000000028ce 00 CH_DOWN Streamzap_PC_Remote<br />
00000000000028c8 00 8 Streamzap_PC_Remote<br />
00000000000028c5 00 5 Streamzap_PC_Remote<br />
00000000000028d2 00 OK Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d1 01 LEFT Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
<br />
{{Note|When the batteries in this remote are low, it may stop working even though the red LED on the received still flashes when you hit buttons!}}<br />
<br />
<br />
=== Serial Port "Home Brew" IR Receiver ===<br />
Here's how to get a "Home Brew" serial port IR receiver working:<br />
<br />
1. Create a udev rule to give non-privleged users read/write access to the serial port. I will be using ttyS0 in my example.<br />
{{hc|/etc/udev/rules.d/z98-serial.rules|<br />
# For serial port ttyS0 and LIRC<br />
KERNEL&#61;&#61;"ttyS0",SUBSYSTEM&#61;&#61;"tty",DRIVERS&#61;&#61;"serial",MODE&#61;"0666"}}<br />
<br />
2. Create the needed modprobe configs<br />
{{hc|/etc/modules-load.d/lirc_serial.conf|lirc_serial}}<br />
{{hc|/etc/modprobe.d/lirc_serial.conf|install lirc_serial /usr/bin/setserial /dev/ttyS0 uart none && /sbin/modprobe --first-time --ignore-install lirc_serial<br />
options lirc_serial type&#61;0<br />
remove lirc_serial /sbin/modprobe -r --first-time --ignore-remove lirc_serial && /sbin/modprobe -r lirc_dev}}<br />
{{Note|Using [[udev]] rules to run the setserial command does not work in my experience because lirc_serial gets loaded before the serial port rules are applied.}}<br />
<br />
3. Install your systemd service file.<br />
{{hc|/etc/systemd/system/lirc.service|[Unit]<br />
Description&#61;Linux Infrared Remote Control<br />
After&#61;network.target<br />
<br />
[Service]<br />
Type&#61;simple<br />
PIDFile&#61;/run/lirc/lircd.pid<br />
ExecStartPre&#61;/bin/rm -f /dev/lirc /dev/lircd /var/run/lirc/lircd<br />
ExecStart&#61;/usr/sbin/lircd -n -r -P /run/lirc/lircd.pid -d /dev/lirc0 -o /run/lirc/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /run/lirc/lircd /dev/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
ExecReload&#61;/bin/kill -SIGHUP $MAINPID<br />
<br />
[Install]<br />
WantedBy&#61;multi-user.target}}<br />
<br />
4. We still need the default tmpfiles to be created, so copy that config file to {{ic|/etc/tmpfiles.d/lirc.conf}}.<br />
{{bc|# cp -a /usr/lib/tmpfiles.d/lirc.conf /etc/tmpfiles.d/lirc.conf}}<br />
<br />
5. Create a {{ic|.lircrc}} file in your home directory for your user or a {{ic|/etc/lirc/lircrc}} file for system wide use.<br />
<br />
6. Have your service start at boot and then test with a reboot<br />
{{bc|1=# systemctl enable lirc.service<br />
# systemctl reboot}}<br />
<br />
or load the module and start the lirc.service.<br />
{{bc|# modprobe lirc_serial<br />
# systemctl start lirc.service}}<br />
<br />
=== Receivers that do not depend on a kernel module ===<br />
<br />
Usually, you only need to specify your the device where the receiver is plugged in and the lirc driver. This is an example for pinnacle or miro serial receivers):<br />
<br />
LIRC_DEVICE="/dev/ttySX"<br />
LIRC_DRIVER="pinsys"<br />
<br />
Then, start lircd daemon and create the remote/s configuration (/etc/lirc/lircd.conf), either by copying one of the configured defaults that comes with lirc-utils or by using irrecord. Even if you find your remote in the list of preconfigured remotes it might not work so you will have to use irrecord anyway.<br />
<br />
After this you can use irw to check the remote, create your ~/.lircrc to assign remote buttons to actions and start irexec if you need to run arbitrary commands.<br />
<br />
==Troubleshooting==<br />
<br />
===Buttons processed several times when pressed===<br />
Problem in module ir_core which processes IR commands with LIRC at the same time. Simply blacklist it by creating the following file:<br />
<br />
{{hc|/etc/modprobe.d/remote_blacklist.conf|<br />
# Prevent processing button several times when pressed<br />
blacklist ir_core<br />
}}<br />
<br />
===After upgrading or installing Arch, an existing configuration stopped working===<br />
====Kernel module change====<br />
As of kernel 2.6.36, LIRC modules have been included in the kernel. Arch's ''lirc'' package has included the older kernel modules, which work with ''lircd'' without any additional configuration. However, a recent update removed those older modules, which results in the stock kernel modules being used. Unfortunately, these kernel modules treat the remote as a keyboard by default, which is incompatible for lircd. To correct this, put the following line to {{ic|/etc/rc.local}}:<br />
{{hc|/etc/rc.local|echo lirc > /sys/class/rc/rc0/protocols}}<br />
You may also run that command as root to enable LIRC for your current session.<br />
<br />
{{Note|It is also a good idea to remove the old LIRC kernel module from your MODULES array in {{ic|/etc/rc.conf}}, as it is no longer present.}}<br />
<br />
=== Problems using default systemd lirc.service file ===<br />
<br />
There is a bug in lirc-utils that makes lirc.service ignore /etc/conf.d/lircd.conf. See [[https://bugs.archlinux.org/task/31890 FS#31890]]<br />
<br />
==See also==<br />
* http://www.mythtv.org/wiki/Category:Remote_Controls -- MythTV wiki main LIRC article<br />
* http://www.mythtv.org/wiki/MCE_Remote -- MythTV wiki on MCE remotes <br />
* http://en.gentoo-wiki.com/wiki/LIRC -- Gentoo wiki LIRC how-to<br />
* https://aur.archlinux.org/packages.php?ID=33849 -- Lirc/Lircrc Configuration Generator</div>Pajarohttps://wiki.archlinux.org/index.php?title=LIRC&diff=242794LIRC2013-01-03T08:13:29Z<p>Pajaro: </p>
<hr />
<div>[[Category:Other hardware]]<br />
[[Category:Audio/Video]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers using LIRC with serial or USB infrared devices.}}<br />
{{Article summary end}}<br />
<br />
[http://lirc.org/ LIRC] stands for "Linux Infrared Remote Control", a program to use infrared devices (like your remote control from your TV) with linux.<br />
<br />
==Supported hardware==<br />
<br />
First of all, check the [http://lirc.org/html/table.html official list of supported hardware]. Check the table to know, which LIRC kernel modules and lircd driver required for your infrared receiver.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] the {{Pkg|lirc-utils}} package, which is available in the [[Official Repositories|official repositories]].<br />
<br />
The most of LIRC kernel drivers are already included in the mainline kernel. You need to install {{Pkg|lirc}} package only, if your hardware requires lirc_atiusb, lirc_i2c or lirc_wpc8769l modules.<br />
<br />
==Serial receivers==<br />
<br />
===Serial receivers that depend on lirc_serial===<br />
<br />
Make sure that your serial port is activated in the BIOS. There you can also set and lookup I/O address and IRQ settings of your ports.<br />
<br />
Now there might be a problem: the module lirc_serial is build to use ttyS0 (COM1), if your device is not connected to ttyS0, you will have to either change the module-options or [[LIRC#Building_the_LIRC_serial_module_for_another_ttySx|rebuild the LIRC module]]. If your device is connected to ttyS0, you can [[LIRC#Loading|skip this step]]<br />
<br />
To change the options for the lirc_serial module, you edit {{ic|/etc/modprobe.d/modprobe.conf}} and add this line:<br />
<br />
options lirc_serial io=0x2f8 irq=3<br />
<br />
You should change the values after io and irq to reflect you serial port settings, the values above may work for you if you are using ttyS1 (COM2) to connect your IR-device. But you will find the correct values by checking dmesg:<br />
<br />
$ dmesg | grep ttyS<br />
<br />
===Other serial receivers===<br />
<br />
See [[LIRC#Other_receivers]]<br />
<br />
===Building the lirc_serial module for another ttySx===<br />
<br />
Update abs<br />
<br />
# abs<br />
<br />
Copy the LIRC files to a directory you choose yourself:<br />
<br />
$ cp /var/abs/extra/system/lirc /some/dir<br />
<br />
$ cd /some/dir<br />
<br />
Edit the PKGBUILD in that directory.<br />
<br />
Replace the line:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=all \\<br />
return 1[/code]<br />
<br />
with:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=com2 \<br />
|| return 1[/code]<br />
<br />
Where you replace com2 with the com-port you need.<br />
<br />
Build and install the package:<br />
<br />
$ makepkg<br />
# pacman -U lirc-version.pkg.tar.gz<br />
<br />
===Loading===<br />
<br />
Now try to load the serial module:<br />
<br />
# modprobe lirc_serial<br />
<br />
If this produces an error which says your serial port is not ready, you have the problem that your serial port support is build into the kernel and not as a module (in the default arch kernel it is build into the kernel)<br />
<br />
If it is built into the kernel you will have to do the following (remember that it is built into the kernel, you will need to make some changes later too)<br />
<br />
You will have to release the serial port:<br />
<br />
# setserial /dev/ttySx uart none<br />
<br />
(Replace x with your port number)<br />
<br />
Load the module again:<br />
<br />
# modprobe lirc_serial<br />
<br />
Now it should not show any errors, and the modules lirc_serial should be listed in lsmod<br />
<br />
==USB receivers including most onboard devices==<br />
This outlines the general procedure, the mceusb module which is used by many devices is used as an example.<br />
<br />
# modprobe mceusb<br />
<br />
Start the LIRC daemon:<br />
<br />
$ /etc/rc.d/lircd start<br />
<br />
Test it with irw, it will output the commands received by the IR receiver that match your {{ic|lircd.conf}} file. So start irw, point your remote and start pressing buttons. <br />
<br />
$ irw<br />
000000037ff07bfe 00 One mceusb<br />
000000037ff07bfd 00 Two mceusb<br />
000000037ff07bfd 01 Two mceusb<br />
000000037ff07bf2 00 Home mceusb<br />
000000037ff07bf2 01 Home mceusb<br />
<br />
The above procedure however has been simplified and may not work that easily. One of the reasons the lircd daemon may not be working is because it expects to be run at startup and needs root permissions because it will create device nodes in {{ic|/dev}}. Try "man lircd" for more information.<br />
<br />
Continue with [[#Making a configuration file]]<br />
<br />
=== Setup a HID device with LIRC ===<br />
Some remotes are supported in the kernel where they are treated as a keyboard and mouse. Every button on the device is recognized as keyboard or mouse events which can be used even without LIRC. LIRC can still be used with these devices to gain greater control over the events raised and integrate with programs that expect a LIRC remote rather than a keyboard. As drivers are migrated to the kernel, devices which use to only be useable through LIRC with their own {{ic|lirc.conf}} files become standard HID devices.<br />
<br />
Some HID remotes actually simulate a USB infrared keyboard and mouse. These remotes show up as two devices so you need to add two LIRC devices to {{ic|lircd.conf}}.<br />
<br />
First we need the {{ic|/dev/input}} device for our remote:<br />
<br />
$ ls /sys/class/rc/rc0<br />
<br />
One of the files should be input''#'', where the number matches the event''#'' of the device. (To clarify you can check that directory, it will have an event''#'' file.<br />
<br />
{{Note|If you have more than one ir device then there may be multiple directories under {{ic|/sys/class/rc}}. Under event''#'' {{ic|cat name}} to verify which device you are looking at.}}<br />
<br />
then go to {{ic|/dev/input/by-id}}<br />
<br />
$ ls -l /dev/input/by-id<br />
<br />
You should find a file that symlinks to the input''#'' above, and possibly others with a similar names for mouse events.<br />
<br />
lrwxrwxrwx 1 root root 9 10月 14 06:43 usb-3353_3713-event-if00 -> ../event9<br />
lrwxrwxrwx 1 root root 10 10月 14 06:43 usb-3353_3713-event-if01 -> ../event10<br />
<br />
Here 'usb-3353_3713-event-if00' and 'usb-3353_3713-event-if01' are the Linux input device event for our HID device, one for the keyboard, another for the mouse.<br />
<br />
Then, we need to edit {{ic|/etc/conf.d/lircd.conf}}. This file contains the parameters for LIRC daemon<br />
<br />
#<br />
#Parameters for daemon<br />
#<br />
<br />
LIRC_DEVICE="/dev/input/by-id/usb-3353_3713-event-if00"<br />
LIRC_DRIVER="devinput"<br />
LIRC_EXTRAOPS=""<br />
LIRC_CONFIGFILE="/etc/lirc/lircd.conf"<br />
<br />
{{Note|Here we set up a LIRC device with the id 3353_3713, you should replace it with your own device input event name, whatever it is.}}<br />
<br />
The latest version of the config file for HID remotes exists in the LIRC git repository [http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=blob_plain;f=remotes/devinput/lircd.conf.devinput;hb=HEAD]. Simply save it as {{ic|/etc/lirc/lircd.conf}}.<br />
<br />
In order to launch the LIRC daemon for HID remote, You must enable evdev module first<br />
# modprobe evdev<br />
<br />
{{Note|LIRC 0.8.6 has changed the default socket location from {{ic|/dev/lircd}} to {{ic|/var/run/lirc/lircd}}, but many applications still look for the socket in the old location. Since lirc-utils 0.8.6-3 the {{ic|/etc/rc.d/lircd}} script creates a symlink from {{ic|/dev/lircd}} to the {{ic|/var/run/lirc/lircd}} socket when it starts the lircd daemon and removes the link when the daemon is stopped.}}<br />
<br />
==Other receivers==<br />
<br />
There are many receivers that do not need any kernel module at all. This applies to any type of receiver, including serial receivers and usb receivers. Check the next link to see what kernel modules you need to load, if any:<br />
<br />
[http://www.lirc.org/html/table.html LIRC supported devices]<br />
<br />
==Checking module based receivers==<br />
<br />
''NOTE: This section only applies if your device requires a lirc_[driver] kernel module.''<br />
<br />
Before you start using lirc, you should check if your receiver is working, and if there is IR interference. Possible sources of interference include monitors/televisions (especially plasma displays), fluorescent lamps and direct or ambient sunlight. Start the following command to display raw receiver input.<br />
<br />
# mode2 -d /dev/lirc0 <br />
<br />
If you press buttons on any IR remote, you should see a series of pulses and spaces. If there is very frequent output without pressing buttons on your remote, your receiver suffers from interference. You want to avoid such interference, e.g. by placing the receiver behind or under your plasma tv.<br />
<br />
If you can't make out where the interference is coming from, you can try to put a cardboard roll right in front of the receiving diode, so that it only gets light from a specific direction. Invoke mode2 as above. Then point at different locations till you receive IR noise.<br />
<br />
==LIRC daemon configuration==<br />
<br />
The lircd configuration lives under /etc/conf.d/lircd.conf, and it is all you need to setup your device if it does not require any special kernel module.<br />
<br />
{{Box|IMPORTANT:|lirc-utils package on ArchLinux has a bug. You will have to create your own systemd unit or find another workaround. See [https://bugs.archlinux.org/task/31890 bug#31890] |#DF0000|#FFDFDF}}<br />
<br />
==Making a configuration file==<br />
<br />
You need a configuration file for your remote control copied or symlinked to {{ic|/etc/lirc/lircd.conf}}. A number of devices have already been included with the lirc package, they can be found in {{ic|/usr/share/lirc/remotes}}. If your specific device is not included, the LIRC site offers configuration files for a large number of extra [http://lirc.sourceforge.net/remotes/ devices].<br />
<br />
If your device does not already have a config file, you can create it yourself with the following command. You should avoid interference (see above) while creating the config file. <br />
<br />
# irrecord -d /dev/lirc0 /tmp/my_remote<br />
<br />
Just follow the instructions. To get a list of valid button names, refer to the output of<br />
# irrecord --list-namespace<br />
The resulting file, {{ic|/tmp/my_remote}}, should then be copied to {{ic|/etc/lirc/lircd.conf}}. If you want to use several remotes, you repeat the irrecord step with each remote and different filenames, and then concatenate all the resulting files into {{ic|/etc/lirc/lircd.conf}}:<br />
<br />
# cat /tmp/my_remote /tmp/my_remote2 /tmp/my_remote3 > /etc/lirc/lircd.conf<br />
<br />
{{Note|As of lirc-0.8.6 the default location of lircd, lircmd and lircrcd config files was moved to {{ic|/etc/lirc/lircd.conf}}, {{ic|/etc/lirc/lircmd.conf}} and {{ic|/etc/lirc/lircrc}}. If the config files are not found in that location, they are still searched at the old location in {{ic|/etc/.}}}}<br />
<br />
===Testing===<br />
<br />
First start the lircd daemon:<br />
<br />
# /etc/rc.d/lircd start<br />
<br />
A good way to see if LIRC is running is to run irw.<br />
<br />
$ irw<br />
<br />
When you press a button, you should see something like this:<br />
<br />
0000000000000001 00 play sony2<br />
0000000000000001 01 play sony2<br />
0000000000000001 02 play sony2<br />
0000000000000001 03 play sony2<br />
<br />
In this case the remote is called sony2, the button is called play, and LIRC has seen it 4 times.<br />
<br />
==Run LIRC at bootup==<br />
<br />
Remember if you had to execute the setserial command while [[LIRC#Loading|loading]] the module?<br />
<br />
If so, [[LIRC#Your serial port support is compiled into the kernel|your serial port support is compiled into the kernel]]<br />
<br />
===Your serial port support is compiled as a module in the kernel===<br />
<br />
This is rather easy: you will just have to add lirc_serial to the modules list and lircd to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
===Your serial port support is compiled into the kernel===<br />
<br />
This is more complicated, you cannot just add the lirc_serial to the modules list in {{ic|/etc/rc.conf}}, as the serial port should be released first.<br />
<br />
So I created a custom startup script to fix this problem.<br />
<br />
{{hc|/etc/rc.d/start_lirc|<nowiki><br />
#!/bin/bash<br />
#/etc/rc.d/start_lirc<br />
#releases ttySx and loads lirc_serial module<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy "release ttySx"<br />
setserial /dev/ttySx uart none<br />
#load lirc module<br />
modprobe lirc_serial<br />
stat_done<br />
;;<br />
stop)<br />
stat_busy "unload lirc module"<br />
rmmod lirc_serial<br />
stat_done<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now load the daemons: add "start_lirc" and "lircd" to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
==Program specific configuration==<br />
<br />
===Generate your own lircrc with Mythbuntu's lircrc-generator===<br />
<br />
'''mythbuntu-lircrc-generator''' is intended to be started from a system with LIRC installed. It requires that you choose a remote via the LIRC package or have a {{ic|lircd.conf}} handy prior to running. It will then produce a sane {{ic|.lircrc}} for the current user.<br />
<br />
[https://aur.archlinux.org/packages.php?ID=33849 Mythbuntu's Lirc/Lircrc Generator is available on AUR]<br/><br />
[http://manpages.ubuntu.com/manpages/intrepid/man1/mythbuntu-lirc-generator.1.html Man page]<br />
<br />
===Enable LIRC support in xine===<br />
<br />
Now LIRC works, but you have no program that can communicate with LIRC. This section will explain how to make xine work, but you can use xmms and mplayer (and probably a lot of other programs too) to work with LIRC.<br />
<br />
====Compile xine with LIRC support====<br />
Download the xine-ui PKGBUILD with [https://wiki.archlinux.org/index.php/Arch_Build_System ABS].<br />
<br />
Add " --enable-lirc" to the {{ic|./configure}} line<br />
<br />
Compile:<br />
<br />
$ makepkg<br />
<br />
Uninstall old xine-ui and install the new one<br />
<br />
# pacman -R xine-ui<br />
# pacman -U xine-filename.pkg.tar.gz<br />
<br />
====Configure xine to use LIRC====<br />
<br />
Let xine produce a default {{ic|.lircrc}} file. In your home directory, type:<br />
<br />
$ xine --keymap=lirc>.lircrc<br />
<br />
Now, in order to have a functioning xine+lirc, edit the {{ic|.lircrc}} file to your preferences.<br />
<br />
However, you may choose to configure LIRC to control more than just xine. If this is the case, you will need to manually edit the {{ic|.lircrc}} file, and add elements. <br />
<br />
Xine-ui<br />
Mplayer<br />
Totem<br />
Vlc<br />
Rhythmbox <br />
<br />
All work with LIRC, but you must enable LIRC support in the program in some cases, such as VLC. Simply copy the vlc packagebuild and edit it so that "--enable-lirc" is one of the compile options for VLC not FFMPEG!<br />
<br />
===Configure Amarok2 to use LIRC===<br />
<br />
Depending on your controller model, the following configuration works with Amarok2-svn. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##amarok2<br />
<br />
begin<br />
button = Play<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Play<br />
end<br />
<br />
begin<br />
button = Pause<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Pause<br />
end<br />
<br />
begin<br />
button = Stop<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Stop<br />
end<br />
<br />
begin<br />
button = Skip<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Next<br />
end<br />
<br />
begin<br />
button = Replay<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Prev<br />
end}}<br />
<br />
===Configure Audacious(2) to use LIRC===<br />
Depending on your controller model, the following configuration works with all versions of Audacious, including the mercurial builds. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##audacious<br />
<br />
begin<br />
prog = audacious<br />
button = Play<br />
config = PLAY<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Pause<br />
config = PAUSE<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Stop<br />
config = STOP<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Skip<br />
config = NEXT<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Replay<br />
config = PREV<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolUp<br />
config = VOL_UP<br />
repeat = 1<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolDown<br />
config = VOL_DOWN<br />
repeat = 1<br />
end}}<br />
<br />
Additionally, there are other values that may be set according to the model set forth above. This was taken from the lirc.c file from audacious-plugins source code:<br />
<br />
{{hc|lirc.c|PLAY<br />
STOP<br />
PAUSE<br />
PLAYPAUSE<br />
NEXT<br />
PREV<br />
SHUFFLE<br />
REPEAT<br />
FWD<br />
BWD<br />
VOL_UP<br />
VOL_DOWN<br />
QUIT<br />
MUTE<br />
BAL_LEFT<br />
BAL_RIGHT<br />
BAL_CENTER<br />
LIST<br />
PLAYLIST_CLEAR<br />
PLAYLIST_ADD}}<br />
<br />
===Configure Mplayer to use LIRC===<br />
<br />
{{hc|~/.lircrc|2=##mplayer<br />
<br />
begin<br />
button = PLAY/PAUSE<br />
prog = mplayer<br />
config = pause<br />
repeat = 1<br />
end<br />
begin<br />
button = FWD<br />
prog = mplayer<br />
config = seek 5<br />
end<br />
begin<br />
button = REV<br />
prog = mplayer<br />
config = seek -5<br />
end<br />
begin<br />
button = MAXIMIZE<br />
prog = mplayer<br />
config = vo_fullscreen<br />
end<br />
}}<br />
<br />
only change PLAY/PAUSE, FWD etc. on keys from your /etc/lircd.conf<br />
<br />
==Device Specific Examples==<br />
=== X10 ===<br />
There is a dedicated wiki page with information about [[X10]]<br />
<br />
===Asus DH Deluxe series motherboard===<br />
Check the output of:<br />
{{bc|$ cat /dev/usb/hiddevX}}<br />
<br />
where X is 0,1 or bigger, and press some buttons on remote.<br />
If you can see reply, device works fine, follow steps:<br><br />
<br />
1. In file {{ic|/etc/conf.d/lircd.conf}} add:<br><br />
{{bc|1=LIRC_DRIVER="dvico"}}<br />
2. Reload LIRC: <br />
{{bc|/etc/rc.d/lircd restart}}<br />
<br />
===ASRock ION series (Nuvoton) quickstart===<br />
<br />
$ ln -s /usr/share/lirc/remotes/lirc_wb677/lircd.conf.wb677 /etc/lirc/lircd.conf<br />
$ /etc/rc.d/lircd restart<br />
<br />
===Streamzap PC Remote (USB)===<br />
{{Note|Xorg now auto recognizes this remote as a keybaord!}} <br />
To disable this behavior, add the following to {{ic|/etc/X11/xorg.conf.d/90-streamzap.conf}}:<br />
{{bc|Section "InputClass"<br />
Identifier "Ignore Streamzap IR"<br />
MatchProduct "Streamzap"<br />
MatchIsKeyboard "true"<br />
Option "Ignore" "true"<br />
EndSection}}<br />
<br />
#Install both packages (lirc lirc-utils)<br />
#Modprobe both kernel mods (lirc_dev and streamzap) (add these to your MODULES array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Create your {{ic|/etc/lirc/lircd.conf}} (for this remote, copy {{ic|/usr/share/lirc/remotes/streamzap/lircd.conf.streamzap}} to {{ic|/etc/lirc/lircd.conf}})<br />
#Start lircd via /etc/rc.d/lircd start (add lircd to your DAEMONS array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Test the remote/lirc with irw<br />
<br />
$ irw<br />
00000000000028cc 00 CH_UP Streamzap_PC_Remote<br />
00000000000028ce 00 CH_DOWN Streamzap_PC_Remote<br />
00000000000028c8 00 8 Streamzap_PC_Remote<br />
00000000000028c5 00 5 Streamzap_PC_Remote<br />
00000000000028d2 00 OK Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d1 01 LEFT Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
<br />
{{Note|When the batteries in this remote are low, it may stop working even though the red LED on the received still flashes when you hit buttons!}}<br />
<br />
<br />
=== Serial Port "Home Brew" IR Receiver ===<br />
Here's how to get a "Home Brew" serial port IR receiver working:<br />
<br />
1. Create a udev rule to give non-privleged users read/write access to the serial port. I will be using ttyS0 in my example.<br />
{{hc|/etc/udev/rules.d/z98-serial.rules|<br />
# For serial port ttyS0 and LIRC<br />
KERNEL&#61;&#61;"ttyS0",SUBSYSTEM&#61;&#61;"tty",DRIVERS&#61;&#61;"serial",MODE&#61;"0666"}}<br />
<br />
2. Create the needed modprobe configs<br />
{{hc|/etc/modules-load.d/lirc_serial.conf|lirc_serial}}<br />
{{hc|/etc/modprobe.d/lirc_serial.conf|install lirc_serial /usr/bin/setserial /dev/ttyS0 uart none && /sbin/modprobe --first-time --ignore-install lirc_serial<br />
options lirc_serial type&#61;0<br />
remove lirc_serial /sbin/modprobe -r --first-time --ignore-remove lirc_serial && /sbin/modprobe -r lirc_dev}}<br />
{{Note|Using [[udev]] rules to run the setserial command does not work in my experience because lirc_serial gets loaded before the serial port rules are applied.}}<br />
<br />
3. Install your systemd service file.<br />
{{hc|/etc/systemd/system/lirc.service|[Unit]<br />
Description&#61;Linux Infrared Remote Control<br />
After&#61;network.target<br />
<br />
[Service]<br />
Type&#61;simple<br />
PIDFile&#61;/run/lirc/lircd.pid<br />
ExecStartPre&#61;/bin/rm -f /dev/lirc /dev/lircd /var/run/lirc/lircd<br />
ExecStart&#61;/usr/sbin/lircd -n -r -P /run/lirc/lircd.pid -d /dev/lirc0 -o /run/lirc/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /run/lirc/lircd /dev/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
ExecReload&#61;/bin/kill -SIGHUP $MAINPID<br />
<br />
[Install]<br />
WantedBy&#61;multi-user.target}}<br />
<br />
4. We still need the default tmpfiles to be created, so copy that config file to {{ic|/etc/tmpfiles.d/lirc.conf}}.<br />
{{bc|# cp -a /usr/lib/tmpfiles.d/lirc.conf /etc/tmpfiles.d/lirc.conf}}<br />
<br />
5. Create a {{ic|.lircrc}} file in your home directory for your user or a {{ic|/etc/lirc/lircrc}} file for system wide use.<br />
<br />
6. Have your service start at boot and then test with a reboot<br />
{{bc|1=# systemctl enable lirc.service<br />
# systemctl reboot}}<br />
<br />
or load the module and start the lirc.service.<br />
{{bc|# modprobe lirc_serial<br />
# systemctl start lirc.service}}<br />
<br />
=== Receivers that do not depend on a kernel module ===<br />
<br />
Usually, you only need to specify your the device where the receiver is plugged in and the lirc driver. This is an example for pinnacle or miro serial receivers):<br />
<br />
LIRC_DEVICE="/dev/ttySX"<br />
LIRC_DRIVER="pinsys"<br />
<br />
Then, start lircd daemon and create the remote/s configuration (/etc/lirc/lircd.conf), either by copying one of the configured defaults that comes with lirc-utils or by using irrecord. Even if you find your remote in the list of preconfigured remotes it might not work so you will have to use irrecord anyway.<br />
<br />
After this you can use irw to check the remote, create your ~/.lircrc to assign remote buttons to actions and start irexec if you need to run arbitrary commands.<br />
<br />
==Troubleshooting==<br />
<br />
===Buttons processed several times when pressed===<br />
Problem in module ir_core which processes IR commands with LIRC at the same time. Simply blacklist it by creating the following file:<br />
<br />
{{hc|/etc/modprobe.d/remote_blacklist.conf|<br />
# Prevent processing button several times when pressed<br />
blacklist ir_core<br />
}}<br />
<br />
===After upgrading or installing Arch, an existing configuration stopped working===<br />
====Kernel module change====<br />
As of kernel 2.6.36, LIRC modules have been included in the kernel. Arch's ''lirc'' package has included the older kernel modules, which work with ''lircd'' without any additional configuration. However, a recent update removed those older modules, which results in the stock kernel modules being used. Unfortunately, these kernel modules treat the remote as a keyboard by default, which is incompatible for lircd. To correct this, put the following line to {{ic|/etc/rc.local}}:<br />
{{hc|/etc/rc.local|echo lirc > /sys/class/rc/rc0/protocols}}<br />
You may also run that command as root to enable LIRC for your current session.<br />
<br />
{{Note|It is also a good idea to remove the old LIRC kernel module from your MODULES array in {{ic|/etc/rc.conf}}, as it is no longer present.}}<br />
<br />
=== Problems using default systemd lirc.service file ===<br />
<br />
lircd log complains:<br />
{{bc|<br />
could not get file information for /dev/lirc<br />
default_init(): No such file or directory<br />
}}<br />
<br />
Solution is to add a symbolic link for {{ic|/dev/lirc}} before starting the lirc daemon.<br />
<br />
1. Copy the system default {{ic|lirc.service}} file to {{ic|/etc/systemd/system/}}<br />
{{bc|# cp /usr/lib/systemd/system/lirc.service /etc/systemd/system/lirc.service}}<br />
<br />
2. Add the following line to {{ic|/etc/systemd/system/lirc.service}}:<br />
{{bc|<nowiki><br />
ExecStartPre=/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
</nowiki>}}<br />
<br />
So now it looks like:<br />
{{hc|/etc/systemd/system/lirc.service<br />
|<nowiki><br />
[Unit]<br />
Description=Linux Infrared Remote Control<br />
<br />
[Service]<br />
EnvironmentFile=/etc/conf.d/lircd.conf<br />
ExecStartPre=/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
ExecStartPre=/usr/bin/ln -sf /run/lirc/lircd /dev/lircd<br />
ExecStart=/usr/sbin/lircd --pidfile=/run/lirc/lircd.pid<br />
Type=forking<br />
PIDFile=/run/lirc/lircd.pid<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
3. disable/enable the lirc service to use the new service file {{ic|/etc/systemd/system/lirc.service}}<br />
{{bc|# systemctl disable lirc<br />
# systemctl enable lirc}}<br />
<br />
4. Restart the service<br />
{{bc|# systemctl restart lirc}}<br />
<br />
{{Note|Make sure you have the correct configuration file in {{ic|/etc/lirc/lircd.conf}}. Copy or link one from {{ic|/usr/share/lirc/remotes}} }}<br />
<br />
==See also==<br />
* http://www.mythtv.org/wiki/Category:Remote_Controls -- MythTV wiki main LIRC article<br />
* http://www.mythtv.org/wiki/MCE_Remote -- MythTV wiki on MCE remotes <br />
* http://en.gentoo-wiki.com/wiki/LIRC -- Gentoo wiki LIRC how-to<br />
* https://aur.archlinux.org/packages.php?ID=33849 -- Lirc/Lircrc Configuration Generator</div>Pajarohttps://wiki.archlinux.org/index.php?title=LIRC&diff=242793LIRC2013-01-03T08:12:18Z<p>Pajaro: </p>
<hr />
<div>[[Category:Other hardware]]<br />
[[Category:Audio/Video]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers using LIRC with serial or USB infrared devices.}}<br />
{{Article summary end}}<br />
<br />
[http://lirc.org/ LIRC] stands for "Linux Infrared Remote Control", a program to use infrared devices (like your remote control from your TV) with linux.<br />
<br />
==Supported hardware==<br />
<br />
First of all, check the [http://lirc.org/html/table.html official list of supported hardware]. Check the table to know, which LIRC kernel modules and lircd driver required for your infrared receiver.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] the {{Pkg|lirc-utils}} package, which is available in the [[Official Repositories|official repositories]].<br />
<br />
The most of LIRC kernel drivers are already included in the mainline kernel. You need to install {{Pkg|lirc}} package only, if your hardware requires lirc_atiusb, lirc_i2c or lirc_wpc8769l modules.<br />
<br />
==Serial receivers==<br />
<br />
===Serial receivers that depend on lirc_serial===<br />
<br />
Make sure that your serial port is activated in the BIOS. There you can also set and lookup I/O address and IRQ settings of your ports.<br />
<br />
Now there might be a problem: the module lirc_serial is build to use ttyS0 (COM1), if your device is not connected to ttyS0, you will have to either change the module-options or [[LIRC#Building_the_LIRC_serial_module_for_another_ttySx|rebuild the LIRC module]]. If your device is connected to ttyS0, you can [[LIRC#Loading|skip this step]]<br />
<br />
To change the options for the lirc_serial module, you edit {{ic|/etc/modprobe.d/modprobe.conf}} and add this line:<br />
<br />
options lirc_serial io=0x2f8 irq=3<br />
<br />
You should change the values after io and irq to reflect you serial port settings, the values above may work for you if you are using ttyS1 (COM2) to connect your IR-device. But you will find the correct values by checking dmesg:<br />
<br />
$ dmesg | grep ttyS<br />
<br />
===Other serial receivers===<br />
<br />
See [[LIRC#Other_receivers]]<br />
<br />
===Building the lirc_serial module for another ttySx===<br />
<br />
Update abs<br />
<br />
# abs<br />
<br />
Copy the LIRC files to a directory you choose yourself:<br />
<br />
$ cp /var/abs/extra/system/lirc /some/dir<br />
<br />
$ cd /some/dir<br />
<br />
Edit the PKGBUILD in that directory.<br />
<br />
Replace the line:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=all \\<br />
return 1[/code]<br />
<br />
with:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=com2 \<br />
|| return 1[/code]<br />
<br />
Where you replace com2 with the com-port you need.<br />
<br />
Build and install the package:<br />
<br />
$ makepkg<br />
# pacman -U lirc-version.pkg.tar.gz<br />
<br />
===Loading===<br />
<br />
Now try to load the serial module:<br />
<br />
# modprobe lirc_serial<br />
<br />
If this produces an error which says your serial port is not ready, you have the problem that your serial port support is build into the kernel and not as a module (in the default arch kernel it is build into the kernel)<br />
<br />
If it is built into the kernel you will have to do the following (remember that it is built into the kernel, you will need to make some changes later too)<br />
<br />
You will have to release the serial port:<br />
<br />
# setserial /dev/ttySx uart none<br />
<br />
(Replace x with your port number)<br />
<br />
Load the module again:<br />
<br />
# modprobe lirc_serial<br />
<br />
Now it should not show any errors, and the modules lirc_serial should be listed in lsmod<br />
<br />
==USB receivers including most onboard devices==<br />
This outlines the general procedure, the mceusb module which is used by many devices is used as an example.<br />
<br />
# modprobe mceusb<br />
<br />
Start the LIRC daemon:<br />
<br />
$ /etc/rc.d/lircd start<br />
<br />
Test it with irw, it will output the commands received by the IR receiver that match your {{ic|lircd.conf}} file. So start irw, point your remote and start pressing buttons. <br />
<br />
$ irw<br />
000000037ff07bfe 00 One mceusb<br />
000000037ff07bfd 00 Two mceusb<br />
000000037ff07bfd 01 Two mceusb<br />
000000037ff07bf2 00 Home mceusb<br />
000000037ff07bf2 01 Home mceusb<br />
<br />
The above procedure however has been simplified and may not work that easily. One of the reasons the lircd daemon may not be working is because it expects to be run at startup and needs root permissions because it will create device nodes in {{ic|/dev}}. Try "man lircd" for more information.<br />
<br />
Continue with [[#Making a configuration file]]<br />
<br />
=== Setup a HID device with LIRC ===<br />
Some remotes are supported in the kernel where they are treated as a keyboard and mouse. Every button on the device is recognized as keyboard or mouse events which can be used even without LIRC. LIRC can still be used with these devices to gain greater control over the events raised and integrate with programs that expect a LIRC remote rather than a keyboard. As drivers are migrated to the kernel, devices which use to only be useable through LIRC with their own {{ic|lirc.conf}} files become standard HID devices.<br />
<br />
Some HID remotes actually simulate a USB infrared keyboard and mouse. These remotes show up as two devices so you need to add two LIRC devices to {{ic|lircd.conf}}.<br />
<br />
First we need the {{ic|/dev/input}} device for our remote:<br />
<br />
$ ls /sys/class/rc/rc0<br />
<br />
One of the files should be input''#'', where the number matches the event''#'' of the device. (To clarify you can check that directory, it will have an event''#'' file.<br />
<br />
{{Note|If you have more than one ir device then there may be multiple directories under {{ic|/sys/class/rc}}. Under event''#'' {{ic|cat name}} to verify which device you are looking at.}}<br />
<br />
then go to {{ic|/dev/input/by-id}}<br />
<br />
$ ls -l /dev/input/by-id<br />
<br />
You should find a file that symlinks to the input''#'' above, and possibly others with a similar names for mouse events.<br />
<br />
lrwxrwxrwx 1 root root 9 10月 14 06:43 usb-3353_3713-event-if00 -> ../event9<br />
lrwxrwxrwx 1 root root 10 10月 14 06:43 usb-3353_3713-event-if01 -> ../event10<br />
<br />
Here 'usb-3353_3713-event-if00' and 'usb-3353_3713-event-if01' are the Linux input device event for our HID device, one for the keyboard, another for the mouse.<br />
<br />
Then, we need to edit {{ic|/etc/conf.d/lircd.conf}}. This file contains the parameters for LIRC daemon<br />
<br />
#<br />
#Parameters for daemon<br />
#<br />
<br />
LIRC_DEVICE="/dev/input/by-id/usb-3353_3713-event-if00"<br />
LIRC_DRIVER="devinput"<br />
LIRC_EXTRAOPS=""<br />
LIRC_CONFIGFILE="/etc/lirc/lircd.conf"<br />
<br />
{{Note|Here we set up a LIRC device with the id 3353_3713, you should replace it with your own device input event name, whatever it is.}}<br />
<br />
The latest version of the config file for HID remotes exists in the LIRC git repository [http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=blob_plain;f=remotes/devinput/lircd.conf.devinput;hb=HEAD]. Simply save it as {{ic|/etc/lirc/lircd.conf}}.<br />
<br />
In order to launch the LIRC daemon for HID remote, You must enable evdev module first<br />
# modprobe evdev<br />
<br />
{{Note|LIRC 0.8.6 has changed the default socket location from {{ic|/dev/lircd}} to {{ic|/var/run/lirc/lircd}}, but many applications still look for the socket in the old location. Since lirc-utils 0.8.6-3 the {{ic|/etc/rc.d/lircd}} script creates a symlink from {{ic|/dev/lircd}} to the {{ic|/var/run/lirc/lircd}} socket when it starts the lircd daemon and removes the link when the daemon is stopped.}}<br />
<br />
==Other receivers==<br />
<br />
There are many receivers that do not need any kernel module at all. This applies to any type of receiver, including serial receivers and usb receivers. Check the next link to see what kernel modules you need to load, if any:<br />
<br />
[http://www.lirc.org/html/table.html LIRC supported devices]<br />
<br />
==Checking module based receivers==<br />
<br />
''NOTE: This section only applies if your device requires a lirc_[driver] kernel module.''<br />
<br />
Before you start using lirc, you should check if your receiver is working, and if there is IR interference. Possible sources of interference include monitors/televisions (especially plasma displays), fluorescent lamps and direct or ambient sunlight. Start the following command to display raw receiver input.<br />
<br />
# mode2 -d /dev/lirc0 <br />
<br />
If you press buttons on any IR remote, you should see a series of pulses and spaces. If there is very frequent output without pressing buttons on your remote, your receiver suffers from interference. You want to avoid such interference, e.g. by placing the receiver behind or under your plasma tv.<br />
<br />
If you can't make out where the interference is coming from, you can try to put a cardboard roll right in front of the receiving diode, so that it only gets light from a specific direction. Invoke mode2 as above. Then point at different locations till you receive IR noise.<br />
<br />
==LIRC daemon configuration==<br />
<br />
The lircd configuration lives under /etc/conf.d/lircd.conf, and it is all you need to setup your device if it does not require any special kernel module.<br />
<br />
{{Box|IMPORTANT:|lirc-utils package on ArchLinux has a bug. You will have to create your own systemd unit or find another workaround. See [https://bugs.archlinux.org/task/31890 bug#31890] |#DF0000|#FFDFDF}}<br />
<br />
==Making a configuration file==<br />
<br />
You need a configuration file for your remote control copied or symlinked to {{ic|/etc/lirc/lircd.conf}}. A number of devices have already been included with the lirc package, they can be found in {{ic|/usr/share/lirc/remotes}}. If your specific device is not included, the LIRC site offers configuration files for a large number of extra [http://lirc.sourceforge.net/remotes/ devices].<br />
<br />
If your device does not already have a config file, you can create it yourself with the following command. You should avoid interference (see above) while creating the config file. <br />
<br />
# irrecord -d /dev/lirc0 /tmp/my_remote<br />
<br />
Just follow the instructions. To get a list of valid button names, refer to the output of<br />
# irrecord --list-namespace<br />
The resulting file, {{ic|/tmp/my_remote}}, should then be copied to {{ic|/etc/lirc/lircd.conf}}. If you want to use several remotes, you repeat the irrecord step with each remote and different filenames, and then concatenate all the resulting files into {{ic|/etc/lirc/lircd.conf}}:<br />
<br />
# cat /tmp/my_remote /tmp/my_remote2 /tmp/my_remote3 > /etc/lirc/lircd.conf<br />
<br />
{{Note|As of lirc-0.8.6 the default location of lircd, lircmd and lircrcd config files was moved to {{ic|/etc/lirc/lircd.conf}}, {{ic|/etc/lirc/lircmd.conf}} and {{ic|/etc/lirc/lircrc}}. If the config files are not found in that location, they are still searched at the old location in {{ic|/etc/.}}}}<br />
<br />
===Testing===<br />
<br />
First start the lircd daemon:<br />
<br />
# /etc/rc.d/lircd start<br />
<br />
A good way to see if LIRC is running is to run irw.<br />
<br />
$ irw<br />
<br />
When you press a button, you should see something like this:<br />
<br />
0000000000000001 00 play sony2<br />
0000000000000001 01 play sony2<br />
0000000000000001 02 play sony2<br />
0000000000000001 03 play sony2<br />
<br />
In this case the remote is called sony2, the button is called play, and LIRC has seen it 4 times.<br />
<br />
==Run LIRC at bootup==<br />
<br />
Remember if you had to execute the setserial command while [[LIRC#Loading|loading]] the module?<br />
<br />
If so, [[LIRC#Your serial port support is compiled into the kernel|your serial port support is compiled into the kernel]]<br />
<br />
===Your serial port support is compiled as a module in the kernel===<br />
<br />
This is rather easy: you will just have to add lirc_serial to the modules list and lircd to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
===Your serial port support is compiled into the kernel===<br />
<br />
This is more complicated, you cannot just add the lirc_serial to the modules list in {{ic|/etc/rc.conf}}, as the serial port should be released first.<br />
<br />
So I created a custom startup script to fix this problem.<br />
<br />
{{hc|/etc/rc.d/start_lirc|<nowiki><br />
#!/bin/bash<br />
#/etc/rc.d/start_lirc<br />
#releases ttySx and loads lirc_serial module<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy "release ttySx"<br />
setserial /dev/ttySx uart none<br />
#load lirc module<br />
modprobe lirc_serial<br />
stat_done<br />
;;<br />
stop)<br />
stat_busy "unload lirc module"<br />
rmmod lirc_serial<br />
stat_done<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now load the daemons: add "start_lirc" and "lircd" to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
==Program specific configuration==<br />
<br />
===Generate your own lircrc with Mythbuntu's lircrc-generator===<br />
<br />
'''mythbuntu-lircrc-generator''' is intended to be started from a system with LIRC installed. It requires that you choose a remote via the LIRC package or have a {{ic|lircd.conf}} handy prior to running. It will then produce a sane {{ic|.lircrc}} for the current user.<br />
<br />
[https://aur.archlinux.org/packages.php?ID=33849 Mythbuntu's Lirc/Lircrc Generator is available on AUR]<br/><br />
[http://manpages.ubuntu.com/manpages/intrepid/man1/mythbuntu-lirc-generator.1.html Man page]<br />
<br />
===Enable LIRC support in xine===<br />
<br />
Now LIRC works, but you have no program that can communicate with LIRC. This section will explain how to make xine work, but you can use xmms and mplayer (and probably a lot of other programs too) to work with LIRC.<br />
<br />
====Compile xine with LIRC support====<br />
Download the xine-ui PKGBUILD with [https://wiki.archlinux.org/index.php/Arch_Build_System ABS].<br />
<br />
Add " --enable-lirc" to the {{ic|./configure}} line<br />
<br />
Compile:<br />
<br />
$ makepkg<br />
<br />
Uninstall old xine-ui and install the new one<br />
<br />
# pacman -R xine-ui<br />
# pacman -U xine-filename.pkg.tar.gz<br />
<br />
====Configure xine to use LIRC====<br />
<br />
Let xine produce a default {{ic|.lircrc}} file. In your home directory, type:<br />
<br />
$ xine --keymap=lirc>.lircrc<br />
<br />
Now, in order to have a functioning xine+lirc, edit the {{ic|.lircrc}} file to your preferences.<br />
<br />
However, you may choose to configure LIRC to control more than just xine. If this is the case, you will need to manually edit the {{ic|.lircrc}} file, and add elements. <br />
<br />
Xine-ui<br />
Mplayer<br />
Totem<br />
Vlc<br />
Rhythmbox <br />
<br />
All work with LIRC, but you must enable LIRC support in the program in some cases, such as VLC. Simply copy the vlc packagebuild and edit it so that "--enable-lirc" is one of the compile options for VLC not FFMPEG!<br />
<br />
===Configure Amarok2 to use LIRC===<br />
<br />
Depending on your controller model, the following configuration works with Amarok2-svn. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##amarok2<br />
<br />
begin<br />
button = Play<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Play<br />
end<br />
<br />
begin<br />
button = Pause<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Pause<br />
end<br />
<br />
begin<br />
button = Stop<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Stop<br />
end<br />
<br />
begin<br />
button = Skip<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Next<br />
end<br />
<br />
begin<br />
button = Replay<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Prev<br />
end}}<br />
<br />
===Configure Audacious(2) to use LIRC===<br />
Depending on your controller model, the following configuration works with all versions of Audacious, including the mercurial builds. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##audacious<br />
<br />
begin<br />
prog = audacious<br />
button = Play<br />
config = PLAY<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Pause<br />
config = PAUSE<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Stop<br />
config = STOP<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Skip<br />
config = NEXT<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Replay<br />
config = PREV<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolUp<br />
config = VOL_UP<br />
repeat = 1<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolDown<br />
config = VOL_DOWN<br />
repeat = 1<br />
end}}<br />
<br />
Additionally, there are other values that may be set according to the model set forth above. This was taken from the lirc.c file from audacious-plugins source code:<br />
<br />
{{hc|lirc.c|PLAY<br />
STOP<br />
PAUSE<br />
PLAYPAUSE<br />
NEXT<br />
PREV<br />
SHUFFLE<br />
REPEAT<br />
FWD<br />
BWD<br />
VOL_UP<br />
VOL_DOWN<br />
QUIT<br />
MUTE<br />
BAL_LEFT<br />
BAL_RIGHT<br />
BAL_CENTER<br />
LIST<br />
PLAYLIST_CLEAR<br />
PLAYLIST_ADD}}<br />
<br />
===Configure Mplayer to use LIRC===<br />
<br />
{{hc|~/.lircrc|2=##mplayer<br />
<br />
begin<br />
button = PLAY/PAUSE<br />
prog = mplayer<br />
config = pause<br />
repeat = 1<br />
end<br />
begin<br />
button = FWD<br />
prog = mplayer<br />
config = seek 5<br />
end<br />
begin<br />
button = REV<br />
prog = mplayer<br />
config = seek -5<br />
end<br />
begin<br />
button = MAXIMIZE<br />
prog = mplayer<br />
config = vo_fullscreen<br />
end<br />
}}<br />
<br />
only change PLAY/PAUSE, FWD etc. on keys from your /etc/lircd.conf<br />
<br />
==Device Specific Examples==<br />
=== X10 ===<br />
There is a dedicated wiki page with information about [[X10]]<br />
<br />
===Asus DH Deluxe series motherboard===<br />
Check the output of:<br />
{{bc|$ cat /dev/usb/hiddevX}}<br />
<br />
where X is 0,1 or bigger, and press some buttons on remote.<br />
If you can see reply, device works fine, follow steps:<br><br />
<br />
1. In file {{ic|/etc/conf.d/lircd.conf}} add:<br><br />
{{bc|1=LIRC_DRIVER="dvico"}}<br />
2. Reload LIRC: <br />
{{bc|/etc/rc.d/lircd restart}}<br />
<br />
===ASRock ION series (Nuvoton) quickstart===<br />
<br />
$ ln -s /usr/share/lirc/remotes/lirc_wb677/lircd.conf.wb677 /etc/lirc/lircd.conf<br />
$ /etc/rc.d/lircd restart<br />
<br />
===Streamzap PC Remote (USB)===<br />
{{Note|Xorg now auto recognizes this remote as a keybaord!}} <br />
To disable this behavior, add the following to {{ic|/etc/X11/xorg.conf.d/90-streamzap.conf}}:<br />
{{bc|Section "InputClass"<br />
Identifier "Ignore Streamzap IR"<br />
MatchProduct "Streamzap"<br />
MatchIsKeyboard "true"<br />
Option "Ignore" "true"<br />
EndSection}}<br />
<br />
#Install both packages (lirc lirc-utils)<br />
#Modprobe both kernel mods (lirc_dev and streamzap) (add these to your MODULES array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Create your {{ic|/etc/lirc/lircd.conf}} (for this remote, copy {{ic|/usr/share/lirc/remotes/streamzap/lircd.conf.streamzap}} to {{ic|/etc/lirc/lircd.conf}})<br />
#Start lircd via /etc/rc.d/lircd start (add lircd to your DAEMONS array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Test the remote/lirc with irw<br />
<br />
$ irw<br />
00000000000028cc 00 CH_UP Streamzap_PC_Remote<br />
00000000000028ce 00 CH_DOWN Streamzap_PC_Remote<br />
00000000000028c8 00 8 Streamzap_PC_Remote<br />
00000000000028c5 00 5 Streamzap_PC_Remote<br />
00000000000028d2 00 OK Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d1 01 LEFT Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
<br />
{{Note|When the batteries in this remote are low, it may stop working even though the red LED on the received still flashes when you hit buttons!}}<br />
<br />
<br />
=== Serial Port "Home Brew" IR Receiver ===<br />
Here's how to get a "Home Brew" serial port IR receiver working:<br />
<br />
1. Create a udev rule to give non-privleged users read/write access to the serial port. I will be using ttyS0 in my example.<br />
{{hc|/etc/udev/rules.d/z98-serial.rules|<br />
# For serial port ttyS0 and LIRC<br />
KERNEL&#61;&#61;"ttyS0",SUBSYSTEM&#61;&#61;"tty",DRIVERS&#61;&#61;"serial",MODE&#61;"0666"}}<br />
<br />
2. Create the needed modprobe configs<br />
{{hc|/etc/modules-load.d/lirc_serial.conf|lirc_serial}}<br />
{{hc|/etc/modprobe.d/lirc_serial.conf|install lirc_serial /usr/bin/setserial /dev/ttyS0 uart none && /sbin/modprobe --first-time --ignore-install lirc_serial<br />
options lirc_serial type&#61;0<br />
remove lirc_serial /sbin/modprobe -r --first-time --ignore-remove lirc_serial && /sbin/modprobe -r lirc_dev}}<br />
{{Note|Using [[udev]] rules to run the setserial command does not work in my experience because lirc_serial gets loaded before the serial port rules are applied.}}<br />
<br />
3. Install your systemd service file.<br />
{{hc|/etc/systemd/system/lirc.service|[Unit]<br />
Description&#61;Linux Infrared Remote Control<br />
After&#61;network.target<br />
<br />
[Service]<br />
Type&#61;simple<br />
PIDFile&#61;/run/lirc/lircd.pid<br />
ExecStartPre&#61;/bin/rm -f /dev/lirc /dev/lircd /var/run/lirc/lircd<br />
ExecStart&#61;/usr/sbin/lircd -n -r -P /run/lirc/lircd.pid -d /dev/lirc0 -o /run/lirc/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /run/lirc/lircd /dev/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
ExecReload&#61;/bin/kill -SIGHUP $MAINPID<br />
<br />
[Install]<br />
WantedBy&#61;multi-user.target}}<br />
<br />
4. We still need the default tmpfiles to be created, so copy that config file to {{ic|/etc/tmpfiles.d/lirc.conf}}.<br />
{{bc|# cp -a /usr/lib/tmpfiles.d/lirc.conf /etc/tmpfiles.d/lirc.conf}}<br />
<br />
5. Create a {{ic|.lircrc}} file in your home directory for your user or a {{ic|/etc/lirc/lircrc}} file for system wide use.<br />
<br />
6. Have your service start at boot and then test with a reboot<br />
{{bc|1=# systemctl enable lirc.service<br />
# systemctl reboot}}<br />
<br />
or load the module and start the lirc.service.<br />
{{bc|# modprobe lirc_serial<br />
# systemctl start lirc.service}}<br />
<br />
=== Receivers that do not depend on a kernel module ===<br />
<br />
Usually, you only need to specify your the device where the receiver is plugged in and the lirc driver. This is an example for finacle or miro serial receivers):<br />
<br />
LIRC_DEVICE="/dev/ttySX"<br />
LIRC_DRIVER="pinsys"<br />
<br />
Then, start lircd daemon and create the remote/s configuration (/etc/lirc/lircd.conf), either by copying one of the configured defaults that comes with lirc-utils or by using irrecord. Even if you find your remote in the list of preconfigured remotes it might not work so you will have to use irrecord anyway.<br />
<br />
After this you can use irw to check the remote, create your ~/.lircrc to assign remote buttons to actions and start irexec if you need to run arbitrary commands.<br />
<br />
==Troubleshooting==<br />
<br />
===Buttons processed several times when pressed===<br />
Problem in module ir_core which processes IR commands with LIRC at the same time. Simply blacklist it by creating the following file:<br />
<br />
{{hc|/etc/modprobe.d/remote_blacklist.conf|<br />
# Prevent processing button several times when pressed<br />
blacklist ir_core<br />
}}<br />
<br />
===After upgrading or installing Arch, an existing configuration stopped working===<br />
====Kernel module change====<br />
As of kernel 2.6.36, LIRC modules have been included in the kernel. Arch's ''lirc'' package has included the older kernel modules, which work with ''lircd'' without any additional configuration. However, a recent update removed those older modules, which results in the stock kernel modules being used. Unfortunately, these kernel modules treat the remote as a keyboard by default, which is incompatible for lircd. To correct this, put the following line to {{ic|/etc/rc.local}}:<br />
{{hc|/etc/rc.local|echo lirc > /sys/class/rc/rc0/protocols}}<br />
You may also run that command as root to enable LIRC for your current session.<br />
<br />
{{Note|It is also a good idea to remove the old LIRC kernel module from your MODULES array in {{ic|/etc/rc.conf}}, as it is no longer present.}}<br />
<br />
=== Problems using default systemd lirc.service file ===<br />
<br />
lircd log complains:<br />
{{bc|<br />
could not get file information for /dev/lirc<br />
default_init(): No such file or directory<br />
}}<br />
<br />
Solution is to add a symbolic link for {{ic|/dev/lirc}} before starting the lirc daemon.<br />
<br />
1. Copy the system default {{ic|lirc.service}} file to {{ic|/etc/systemd/system/}}<br />
{{bc|# cp /usr/lib/systemd/system/lirc.service /etc/systemd/system/lirc.service}}<br />
<br />
2. Add the following line to {{ic|/etc/systemd/system/lirc.service}}:<br />
{{bc|<nowiki><br />
ExecStartPre=/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
</nowiki>}}<br />
<br />
So now it looks like:<br />
{{hc|/etc/systemd/system/lirc.service<br />
|<nowiki><br />
[Unit]<br />
Description=Linux Infrared Remote Control<br />
<br />
[Service]<br />
EnvironmentFile=/etc/conf.d/lircd.conf<br />
ExecStartPre=/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
ExecStartPre=/usr/bin/ln -sf /run/lirc/lircd /dev/lircd<br />
ExecStart=/usr/sbin/lircd --pidfile=/run/lirc/lircd.pid<br />
Type=forking<br />
PIDFile=/run/lirc/lircd.pid<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
3. disable/enable the lirc service to use the new service file {{ic|/etc/systemd/system/lirc.service}}<br />
{{bc|# systemctl disable lirc<br />
# systemctl enable lirc}}<br />
<br />
4. Restart the service<br />
{{bc|# systemctl restart lirc}}<br />
<br />
{{Note|Make sure you have the correct configuration file in {{ic|/etc/lirc/lircd.conf}}. Copy or link one from {{ic|/usr/share/lirc/remotes}} }}<br />
<br />
==See also==<br />
* http://www.mythtv.org/wiki/Category:Remote_Controls -- MythTV wiki main LIRC article<br />
* http://www.mythtv.org/wiki/MCE_Remote -- MythTV wiki on MCE remotes <br />
* http://en.gentoo-wiki.com/wiki/LIRC -- Gentoo wiki LIRC how-to<br />
* https://aur.archlinux.org/packages.php?ID=33849 -- Lirc/Lircrc Configuration Generator</div>Pajarohttps://wiki.archlinux.org/index.php?title=LIRC&diff=242761LIRC2013-01-02T22:47:43Z<p>Pajaro: </p>
<hr />
<div>[[Category:Other hardware]]<br />
[[Category:Audio/Video]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers using LIRC with serial or USB infrared devices.}}<br />
{{Article summary end}}<br />
<br />
[http://lirc.org/ LIRC] stands for "Linux Infrared Remote Control", a program to use infrared devices (like your remote control from your TV) with linux.<br />
<br />
==Supported hardware==<br />
<br />
First of all, check the [http://lirc.org/html/table.html official list of supported hardware]. Check the table to know, which LIRC kernel modules and lircd driver required for your infrared receiver.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] the {{Pkg|lirc-utils}} package, which is available in the [[Official Repositories|official repositories]].<br />
<br />
The most of LIRC kernel drivers are already included in the mainline kernel. You need to install {{Pkg|lirc}} package only, if your hardware requires lirc_atiusb, lirc_i2c or lirc_wpc8769l modules.<br />
<br />
==Serial receivers==<br />
<br />
===Serial receivers that depend on lirc_serial===<br />
<br />
Make sure that your serial port is activated in the BIOS. There you can also set and lookup I/O address and IRQ settings of your ports.<br />
<br />
Now there might be a problem: the module lirc_serial is build to use ttyS0 (COM1), if your device is not connected to ttyS0, you will have to either change the module-options or [[LIRC#Building_the_LIRC_serial_module_for_another_ttySx|rebuild the LIRC module]]. If your device is connected to ttyS0, you can [[LIRC#Loading|skip this step]]<br />
<br />
To change the options for the lirc_serial module, you edit {{ic|/etc/modprobe.d/modprobe.conf}} and add this line:<br />
<br />
options lirc_serial io=0x2f8 irq=3<br />
<br />
You should change the values after io and irq to reflect you serial port settings, the values above may work for you if you are using ttyS1 (COM2) to connect your IR-device. But you will find the correct values by checking dmesg:<br />
<br />
$ dmesg | grep ttyS<br />
<br />
===Other serial receivers===<br />
<br />
See [[LIRC#Other_receivers]]<br />
<br />
===Building the lirc_serial module for another ttySx===<br />
<br />
Update abs<br />
<br />
# abs<br />
<br />
Copy the LIRC files to a directory you choose yourself:<br />
<br />
$ cp /var/abs/extra/system/lirc /some/dir<br />
<br />
$ cd /some/dir<br />
<br />
Edit the PKGBUILD in that directory.<br />
<br />
Replace the line:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=all \\<br />
return 1[/code]<br />
<br />
with:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=com2 \<br />
|| return 1[/code]<br />
<br />
Where you replace com2 with the com-port you need.<br />
<br />
Build and install the package:<br />
<br />
$ makepkg<br />
# pacman -U lirc-version.pkg.tar.gz<br />
<br />
===Loading===<br />
<br />
Now try to load the serial module:<br />
<br />
# modprobe lirc_serial<br />
<br />
If this produces an error which says your serial port is not ready, you have the problem that your serial port support is build into the kernel and not as a module (in the default arch kernel it is build into the kernel)<br />
<br />
If it is built into the kernel you will have to do the following (remember that it is built into the kernel, you will need to make some changes later too)<br />
<br />
You will have to release the serial port:<br />
<br />
# setserial /dev/ttySx uart none<br />
<br />
(Replace x with your port number)<br />
<br />
Load the module again:<br />
<br />
# modprobe lirc_serial<br />
<br />
Now it should not show any errors, and the modules lirc_serial should be listed in lsmod<br />
<br />
==USB receivers including most onboard devices==<br />
This outlines the general procedure, the mceusb module which is used by many devices is used as an example.<br />
<br />
# modprobe mceusb<br />
<br />
Start the LIRC daemon:<br />
<br />
$ /etc/rc.d/lircd start<br />
<br />
Test it with irw, it will output the commands received by the IR receiver that match your {{ic|lircd.conf}} file. So start irw, point your remote and start pressing buttons. <br />
<br />
$ irw<br />
000000037ff07bfe 00 One mceusb<br />
000000037ff07bfd 00 Two mceusb<br />
000000037ff07bfd 01 Two mceusb<br />
000000037ff07bf2 00 Home mceusb<br />
000000037ff07bf2 01 Home mceusb<br />
<br />
The above procedure however has been simplified and may not work that easily. One of the reasons the lircd daemon may not be working is because it expects to be run at startup and needs root permissions because it will create device nodes in {{ic|/dev}}. Try "man lircd" for more information.<br />
<br />
Continue with [[#Making a configuration file]]<br />
<br />
=== Setup a HID device with LIRC ===<br />
Some remotes are supported in the kernel where they are treated as a keyboard and mouse. Every button on the device is recognized as keyboard or mouse events which can be used even without LIRC. LIRC can still be used with these devices to gain greater control over the events raised and integrate with programs that expect a LIRC remote rather than a keyboard. As drivers are migrated to the kernel, devices which use to only be useable through LIRC with their own {{ic|lirc.conf}} files become standard HID devices.<br />
<br />
Some HID remotes actually simulate a USB infrared keyboard and mouse. These remotes show up as two devices so you need to add two LIRC devices to {{ic|lircd.conf}}.<br />
<br />
First we need the {{ic|/dev/input}} device for our remote:<br />
<br />
$ ls /sys/class/rc/rc0<br />
<br />
One of the files should be input''#'', where the number matches the event''#'' of the device. (To clarify you can check that directory, it will have an event''#'' file.<br />
<br />
{{Note|If you have more than one ir device then there may be multiple directories under {{ic|/sys/class/rc}}. Under event''#'' {{ic|cat name}} to verify which device you are looking at.}}<br />
<br />
then go to {{ic|/dev/input/by-id}}<br />
<br />
$ ls -l /dev/input/by-id<br />
<br />
You should find a file that symlinks to the input''#'' above, and possibly others with a similar names for mouse events.<br />
<br />
lrwxrwxrwx 1 root root 9 10月 14 06:43 usb-3353_3713-event-if00 -> ../event9<br />
lrwxrwxrwx 1 root root 10 10月 14 06:43 usb-3353_3713-event-if01 -> ../event10<br />
<br />
Here 'usb-3353_3713-event-if00' and 'usb-3353_3713-event-if01' are the Linux input device event for our HID device, one for the keyboard, another for the mouse.<br />
<br />
Then, we need to edit {{ic|/etc/conf.d/lircd.conf}}. This file contains the parameters for LIRC daemon<br />
<br />
#<br />
#Parameters for daemon<br />
#<br />
<br />
LIRC_DEVICE="/dev/input/by-id/usb-3353_3713-event-if00"<br />
LIRC_DRIVER="devinput"<br />
LIRC_EXTRAOPS=""<br />
LIRC_CONFIGFILE="/etc/lirc/lircd.conf"<br />
<br />
{{Note|Here we set up a LIRC device with the id 3353_3713, you should replace it with your own device input event name, whatever it is.}}<br />
<br />
The latest version of the config file for HID remotes exists in the LIRC git repository [http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=blob_plain;f=remotes/devinput/lircd.conf.devinput;hb=HEAD]. Simply save it as {{ic|/etc/lirc/lircd.conf}}.<br />
<br />
In order to launch the LIRC daemon for HID remote, You must enable evdev module first<br />
# modprobe evdev<br />
<br />
{{Note|LIRC 0.8.6 has changed the default socket location from {{ic|/dev/lircd}} to {{ic|/var/run/lirc/lircd}}, but many applications still look for the socket in the old location. Since lirc-utils 0.8.6-3 the {{ic|/etc/rc.d/lircd}} script creates a symlink from {{ic|/dev/lircd}} to the {{ic|/var/run/lirc/lircd}} socket when it starts the lircd daemon and removes the link when the daemon is stopped.}}<br />
<br />
==Other receivers==<br />
<br />
There are many receivers that do not need any kernel module at all. This applies to any type of receiver, including serial receivers and usb receivers. Check the next link to see what kernel modules you need to load, if any:<br />
<br />
[http://www.lirc.org/html/table.html LIRC supported devices]<br />
<br />
==Checking module based receivers==<br />
<br />
''NOTE: This section only applies if your device requires a lirc_[driver] kernel module.''<br />
<br />
Before you start using lirc, you should check if your receiver is working, and if there is IR interference. Possible sources of interference include monitors/televisions (especially plasma displays), fluorescent lamps and direct or ambient sunlight. Start the following command to display raw receiver input.<br />
<br />
# mode2 -d /dev/lirc0 <br />
<br />
If you press buttons on any IR remote, you should see a series of pulses and spaces. If there is very frequent output without pressing buttons on your remote, your receiver suffers from interference. You want to avoid such interference, e.g. by placing the receiver behind or under your plasma tv.<br />
<br />
If you can't make out where the interference is coming from, you can try to put a cardboard roll right in front of the receiving diode, so that it only gets light from a specific direction. Invoke mode2 as above. Then point at different locations till you receive IR noise.<br />
<br />
==LIRC daemon configuration==<br />
<br />
The lircd configuration lives under /etc/conf.d/lircd.conf, and it is all you need to setup your device if it does not require any special kernel module.<br />
<br />
{{Box|IMPORTANT:|lirc-utils package on ArchLinux has a bug. You will have to create your own systemd unit or find another workaround. See [https://bugs.archlinux.org/task/31890 bug#31890] |#DF0000|#FFDFDF}}<br />
<br />
==Making a configuration file==<br />
<br />
You need a configuration file for your remote control copied or symlinked to {{ic|/etc/lirc/lircd.conf}}. A number of devices have already been included with the lirc package, they can be found in {{ic|/usr/share/lirc/remotes}}. If your specific device is not included, the LIRC site offers configuration files for a large number of extra [http://lirc.sourceforge.net/remotes/ devices].<br />
<br />
If your device does not already have a config file, you can create it yourself with the following command. You should avoid interference (see above) while creating the config file. <br />
<br />
# irrecord -d /dev/lirc0 /tmp/my_remote<br />
<br />
Just follow the instructions. To get a list of valid button names, refer to the output of<br />
# irrecord --list-namespace<br />
The resulting file, {{ic|/tmp/my_remote}}, should then be copied to {{ic|/etc/lirc/lircd.conf}}. If you want to use several remotes, you repeat the irrecord step with each remote and different filenames, and then concatenate all the resulting files into {{ic|/etc/lirc/lircd.conf}}:<br />
<br />
# cat /tmp/my_remote /tmp/my_remote2 /tmp/my_remote3 > /etc/lirc/lircd.conf<br />
<br />
{{Note|As of lirc-0.8.6 the default location of lircd, lircmd and lircrcd config files was moved to {{ic|/etc/lirc/lircd.conf}}, {{ic|/etc/lirc/lircmd.conf}} and {{ic|/etc/lirc/lircrc}}. If the config files are not found in that location, they are still searched at the old location in {{ic|/etc/.}}}}<br />
<br />
===Testing===<br />
<br />
First start the lircd daemon:<br />
<br />
# /etc/rc.d/lircd start<br />
<br />
A good way to see if LIRC is running is to run irw.<br />
<br />
$ irw<br />
<br />
When you press a button, you should see something like this:<br />
<br />
0000000000000001 00 play sony2<br />
0000000000000001 01 play sony2<br />
0000000000000001 02 play sony2<br />
0000000000000001 03 play sony2<br />
<br />
In this case the remote is called sony2, the button is called play, and LIRC has seen it 4 times.<br />
<br />
==Run LIRC at bootup==<br />
<br />
Remember if you had to execute the setserial command while [[LIRC#Loading|loading]] the module?<br />
<br />
If so, [[LIRC#Your serial port support is compiled into the kernel|your serial port support is compiled into the kernel]]<br />
<br />
===Your serial port support is compiled as a module in the kernel===<br />
<br />
This is rather easy: you will just have to add lirc_serial to the modules list and lircd to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
===Your serial port support is compiled into the kernel===<br />
<br />
This is more complicated, you cannot just add the lirc_serial to the modules list in {{ic|/etc/rc.conf}}, as the serial port should be released first.<br />
<br />
So I created a custom startup script to fix this problem.<br />
<br />
{{hc|/etc/rc.d/start_lirc|<nowiki><br />
#!/bin/bash<br />
#/etc/rc.d/start_lirc<br />
#releases ttySx and loads lirc_serial module<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy "release ttySx"<br />
setserial /dev/ttySx uart none<br />
#load lirc module<br />
modprobe lirc_serial<br />
stat_done<br />
;;<br />
stop)<br />
stat_busy "unload lirc module"<br />
rmmod lirc_serial<br />
stat_done<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now load the daemons: add "start_lirc" and "lircd" to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
==Program specific configuration==<br />
<br />
===Generate your own lircrc with Mythbuntu's lircrc-generator===<br />
<br />
'''mythbuntu-lircrc-generator''' is intended to be started from a system with LIRC installed. It requires that you choose a remote via the LIRC package or have a {{ic|lircd.conf}} handy prior to running. It will then produce a sane {{ic|.lircrc}} for the current user.<br />
<br />
[https://aur.archlinux.org/packages.php?ID=33849 Mythbuntu's Lirc/Lircrc Generator is available on AUR]<br/><br />
[http://manpages.ubuntu.com/manpages/intrepid/man1/mythbuntu-lirc-generator.1.html Man page]<br />
<br />
===Enable LIRC support in xine===<br />
<br />
Now LIRC works, but you have no program that can communicate with LIRC. This section will explain how to make xine work, but you can use xmms and mplayer (and probably a lot of other programs too) to work with LIRC.<br />
<br />
====Compile xine with LIRC support====<br />
Download the xine-ui PKGBUILD with [https://wiki.archlinux.org/index.php/Arch_Build_System ABS].<br />
<br />
Add " --enable-lirc" to the {{ic|./configure}} line<br />
<br />
Compile:<br />
<br />
$ makepkg<br />
<br />
Uninstall old xine-ui and install the new one<br />
<br />
# pacman -R xine-ui<br />
# pacman -U xine-filename.pkg.tar.gz<br />
<br />
====Configure xine to use LIRC====<br />
<br />
Let xine produce a default {{ic|.lircrc}} file. In your home directory, type:<br />
<br />
$ xine --keymap=lirc>.lircrc<br />
<br />
Now, in order to have a functioning xine+lirc, edit the {{ic|.lircrc}} file to your preferences.<br />
<br />
However, you may choose to configure LIRC to control more than just xine. If this is the case, you will need to manually edit the {{ic|.lircrc}} file, and add elements. <br />
<br />
Xine-ui<br />
Mplayer<br />
Totem<br />
Vlc<br />
Rhythmbox <br />
<br />
All work with LIRC, but you must enable LIRC support in the program in some cases, such as VLC. Simply copy the vlc packagebuild and edit it so that "--enable-lirc" is one of the compile options for VLC not FFMPEG!<br />
<br />
===Configure Amarok2 to use LIRC===<br />
<br />
Depending on your controller model, the following configuration works with Amarok2-svn. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##amarok2<br />
<br />
begin<br />
button = Play<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Play<br />
end<br />
<br />
begin<br />
button = Pause<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Pause<br />
end<br />
<br />
begin<br />
button = Stop<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Stop<br />
end<br />
<br />
begin<br />
button = Skip<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Next<br />
end<br />
<br />
begin<br />
button = Replay<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Prev<br />
end}}<br />
<br />
===Configure Audacious(2) to use LIRC===<br />
Depending on your controller model, the following configuration works with all versions of Audacious, including the mercurial builds. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##audacious<br />
<br />
begin<br />
prog = audacious<br />
button = Play<br />
config = PLAY<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Pause<br />
config = PAUSE<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Stop<br />
config = STOP<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Skip<br />
config = NEXT<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Replay<br />
config = PREV<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolUp<br />
config = VOL_UP<br />
repeat = 1<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolDown<br />
config = VOL_DOWN<br />
repeat = 1<br />
end}}<br />
<br />
Additionally, there are other values that may be set according to the model set forth above. This was taken from the lirc.c file from audacious-plugins source code:<br />
<br />
{{hc|lirc.c|PLAY<br />
STOP<br />
PAUSE<br />
PLAYPAUSE<br />
NEXT<br />
PREV<br />
SHUFFLE<br />
REPEAT<br />
FWD<br />
BWD<br />
VOL_UP<br />
VOL_DOWN<br />
QUIT<br />
MUTE<br />
BAL_LEFT<br />
BAL_RIGHT<br />
BAL_CENTER<br />
LIST<br />
PLAYLIST_CLEAR<br />
PLAYLIST_ADD}}<br />
<br />
===Configure Mplayer to use LIRC===<br />
<br />
{{hc|~/.lircrc|2=##mplayer<br />
<br />
begin<br />
button = PLAY/PAUSE<br />
prog = mplayer<br />
config = pause<br />
repeat = 1<br />
end<br />
begin<br />
button = FWD<br />
prog = mplayer<br />
config = seek 5<br />
end<br />
begin<br />
button = REV<br />
prog = mplayer<br />
config = seek -5<br />
end<br />
begin<br />
button = MAXIMIZE<br />
prog = mplayer<br />
config = vo_fullscreen<br />
end<br />
}}<br />
<br />
only change PLAY/PAUSE, FWD etc. on keys from your /etc/lircd.conf<br />
<br />
==Device Specific Examples==<br />
=== X10 ===<br />
There is a dedicated wiki page with information about [[X10]]<br />
<br />
===Asus DH Deluxe series motherboard===<br />
Check the output of:<br />
{{bc|$ cat /dev/usb/hiddevX}}<br />
<br />
where X is 0,1 or bigger, and press some buttons on remote.<br />
If you can see reply, device works fine, follow steps:<br><br />
<br />
1. In file {{ic|/etc/conf.d/lircd.conf}} add:<br><br />
{{bc|1=LIRC_DRIVER="dvico"}}<br />
2. Reload LIRC: <br />
{{bc|/etc/rc.d/lircd restart}}<br />
<br />
===ASRock ION series (Nuvoton) quickstart===<br />
<br />
$ ln -s /usr/share/lirc/remotes/lirc_wb677/lircd.conf.wb677 /etc/lirc/lircd.conf<br />
$ /etc/rc.d/lircd restart<br />
<br />
===Streamzap PC Remote (USB)===<br />
{{Note|Xorg now auto recognizes this remote as a keybaord!}} <br />
To disable this behavior, add the following to {{ic|/etc/X11/xorg.conf.d/90-streamzap.conf}}:<br />
{{bc|Section "InputClass"<br />
Identifier "Ignore Streamzap IR"<br />
MatchProduct "Streamzap"<br />
MatchIsKeyboard "true"<br />
Option "Ignore" "true"<br />
EndSection}}<br />
<br />
#Install both packages (lirc lirc-utils)<br />
#Modprobe both kernel mods (lirc_dev and streamzap) (add these to your MODULES array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Create your {{ic|/etc/lirc/lircd.conf}} (for this remote, copy {{ic|/usr/share/lirc/remotes/streamzap/lircd.conf.streamzap}} to {{ic|/etc/lirc/lircd.conf}})<br />
#Start lircd via /etc/rc.d/lircd start (add lircd to your DAEMONS array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Test the remote/lirc with irw<br />
<br />
$ irw<br />
00000000000028cc 00 CH_UP Streamzap_PC_Remote<br />
00000000000028ce 00 CH_DOWN Streamzap_PC_Remote<br />
00000000000028c8 00 8 Streamzap_PC_Remote<br />
00000000000028c5 00 5 Streamzap_PC_Remote<br />
00000000000028d2 00 OK Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d1 01 LEFT Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
<br />
{{Note|When the batteries in this remote are low, it may stop working even though the red LED on the received still flashes when you hit buttons!}}<br />
<br />
<br />
=== Serial Port IR Receiver ===<br />
Here's how to get a "Home Brew" serial port IR receiver working:<br />
<br />
1. Create a udev rule to give non-privleged users read/write access to the serial port. I will be using ttyS0 in my example.<br />
{{hc|/etc/udev/rules.d/z98-serial.rules|<br />
# For serial port ttyS0 and LIRC<br />
KERNEL&#61;&#61;"ttyS0",SUBSYSTEM&#61;&#61;"tty",DRIVERS&#61;&#61;"serial",MODE&#61;"0666"}}<br />
<br />
2. Create the needed modprobe configs<br />
{{hc|/etc/modules-load.d/lirc_serial.conf|lirc_serial}}<br />
{{hc|/etc/modprobe.d/lirc_serial.conf|install lirc_serial /usr/bin/setserial /dev/ttyS0 uart none && /sbin/modprobe --first-time --ignore-install lirc_serial<br />
options lirc_serial type&#61;0<br />
remove lirc_serial /sbin/modprobe -r --first-time --ignore-remove lirc_serial && /sbin/modprobe -r lirc_dev}}<br />
{{Note|Using [[udev]] rules to run the setserial command does not work in my experience because lirc_serial gets loaded before the serial port rules are applied.}}<br />
<br />
3. Install your systemd service file.<br />
{{hc|/etc/systemd/system/lirc.service|[Unit]<br />
Description&#61;Linux Infrared Remote Control<br />
After&#61;network.target<br />
<br />
[Service]<br />
Type&#61;simple<br />
PIDFile&#61;/run/lirc/lircd.pid<br />
ExecStartPre&#61;/bin/rm -f /dev/lirc /dev/lircd /var/run/lirc/lircd<br />
ExecStart&#61;/usr/sbin/lircd -n -r -P /run/lirc/lircd.pid -d /dev/lirc0 -o /run/lirc/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /run/lirc/lircd /dev/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
ExecReload&#61;/bin/kill -SIGHUP $MAINPID<br />
<br />
[Install]<br />
WantedBy&#61;multi-user.target}}<br />
<br />
4. We still need the default tmpfiles to be created, so copy that config file to {{ic|/etc/tmpfiles.d/lirc.conf}}.<br />
{{bc|# cp -a /usr/lib/tmpfiles.d/lirc.conf /etc/tmpfiles.d/lirc.conf}}<br />
<br />
5. Create a {{ic|.lircrc}} file in your home directory for your user or a {{ic|/etc/lirc/lircrc}} file for system wide use.<br />
<br />
6. Have your service start at boot and then test with a reboot<br />
{{bc|1=# systemctl enable lirc.service<br />
# systemctl reboot}}<br />
<br />
or load the module and start the lirc.service.<br />
{{bc|# modprobe lirc_serial<br />
# systemctl start lirc.service}}<br />
<br />
==Troubleshooting==<br />
<br />
===Buttons processed several times when pressed===<br />
Problem in module ir_core which processes IR commands with LIRC at the same time. Simply blacklist it by creating the following file:<br />
<br />
{{hc|/etc/modprobe.d/remote_blacklist.conf|<br />
# Prevent processing button several times when pressed<br />
blacklist ir_core<br />
}}<br />
<br />
===After upgrading or installing Arch, an existing configuration stopped working===<br />
====Kernel module change====<br />
As of kernel 2.6.36, LIRC modules have been included in the kernel. Arch's ''lirc'' package has included the older kernel modules, which work with ''lircd'' without any additional configuration. However, a recent update removed those older modules, which results in the stock kernel modules being used. Unfortunately, these kernel modules treat the remote as a keyboard by default, which is incompatible for lircd. To correct this, put the following line to {{ic|/etc/rc.local}}:<br />
{{hc|/etc/rc.local|echo lirc > /sys/class/rc/rc0/protocols}}<br />
You may also run that command as root to enable LIRC for your current session.<br />
<br />
{{Note|It is also a good idea to remove the old LIRC kernel module from your MODULES array in {{ic|/etc/rc.conf}}, as it is no longer present.}}<br />
<br />
==See also==<br />
* http://www.mythtv.org/wiki/Category:Remote_Controls -- MythTV wiki main LIRC article<br />
* http://www.mythtv.org/wiki/MCE_Remote -- MythTV wiki on MCE remotes <br />
* http://en.gentoo-wiki.com/wiki/LIRC -- Gentoo wiki LIRC how-to<br />
* https://aur.archlinux.org/packages.php?ID=33849 -- Lirc/Lircrc Configuration Generator</div>Pajarohttps://wiki.archlinux.org/index.php?title=LIRC&diff=242758LIRC2013-01-02T22:42:57Z<p>Pajaro: </p>
<hr />
<div>[[Category:Other hardware]]<br />
[[Category:Audio/Video]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers using LIRC with serial or USB infrared devices.}}<br />
{{Article summary end}}<br />
<br />
[http://lirc.org/ LIRC] stands for "Linux Infrared Remote Control", a program to use infrared devices (like your remote control from your TV) with linux.<br />
<br />
==Supported hardware==<br />
<br />
First of all, check the [http://lirc.org/html/table.html official list of supported hardware]. Check the table to know, which LIRC kernel modules and lircd driver required for your infrared receiver.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] the {{Pkg|lirc-utils}} package, which is available in the [[Official Repositories|official repositories]].<br />
<br />
The most of LIRC kernel drivers are already included in the mainline kernel. You need to install {{Pkg|lirc}} package only, if your hardware requires lirc_atiusb, lirc_i2c or lirc_wpc8769l modules.<br />
<br />
==Serial receivers==<br />
<br />
===Serial receivers that depend on lirc_serial===<br />
<br />
Make sure that your serial port is activated in the BIOS. There you can also set and lookup I/O address and IRQ settings of your ports.<br />
<br />
Now there might be a problem: the module lirc_serial is build to use ttyS0 (COM1), if your device is not connected to ttyS0, you will have to either change the module-options or [[LIRC#Building_the_LIRC_serial_module_for_another_ttySx|rebuild the LIRC module]]. If your device is connected to ttyS0, you can [[LIRC#Loading|skip this step]]<br />
<br />
To change the options for the lirc_serial module, you edit {{ic|/etc/modprobe.d/modprobe.conf}} and add this line:<br />
<br />
options lirc_serial io=0x2f8 irq=3<br />
<br />
You should change the values after io and irq to reflect you serial port settings, the values above may work for you if you are using ttyS1 (COM2) to connect your IR-device. But you will find the correct values by checking dmesg:<br />
<br />
$ dmesg | grep ttyS<br />
<br />
===Other serial receivers===<br />
<br />
See [[LIRC#Other_receivers]]<br />
<br />
===Building the lirc_serial module for another ttySx===<br />
<br />
Update abs<br />
<br />
# abs<br />
<br />
Copy the LIRC files to a directory you choose yourself:<br />
<br />
$ cp /var/abs/extra/system/lirc /some/dir<br />
<br />
$ cd /some/dir<br />
<br />
Edit the PKGBUILD in that directory.<br />
<br />
Replace the line:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=all \\<br />
return 1[/code]<br />
<br />
with:<br />
<br />
./configure --enable-sandboxed --prefix=/usr \<br />
--with-driver=com2 \<br />
|| return 1[/code]<br />
<br />
Where you replace com2 with the com-port you need.<br />
<br />
Build and install the package:<br />
<br />
$ makepkg<br />
# pacman -U lirc-version.pkg.tar.gz<br />
<br />
===Loading===<br />
<br />
Now try to load the serial module:<br />
<br />
# modprobe lirc_serial<br />
<br />
If this produces an error which says your serial port is not ready, you have the problem that your serial port support is build into the kernel and not as a module (in the default arch kernel it is build into the kernel)<br />
<br />
If it is built into the kernel you will have to do the following (remember that it is built into the kernel, you will need to make some changes later too)<br />
<br />
You will have to release the serial port:<br />
<br />
# setserial /dev/ttySx uart none<br />
<br />
(Replace x with your port number)<br />
<br />
Load the module again:<br />
<br />
# modprobe lirc_serial<br />
<br />
Now it should not show any errors, and the modules lirc_serial should be listed in lsmod<br />
<br />
==USB receivers including most onboard devices==<br />
This outlines the general procedure, the mceusb module which is used by many devices is used as an example.<br />
<br />
# modprobe mceusb<br />
<br />
Start the LIRC daemon:<br />
<br />
$ /etc/rc.d/lircd start<br />
<br />
Test it with irw, it will output the commands received by the IR receiver that match your {{ic|lircd.conf}} file. So start irw, point your remote and start pressing buttons. <br />
<br />
$ irw<br />
000000037ff07bfe 00 One mceusb<br />
000000037ff07bfd 00 Two mceusb<br />
000000037ff07bfd 01 Two mceusb<br />
000000037ff07bf2 00 Home mceusb<br />
000000037ff07bf2 01 Home mceusb<br />
<br />
The above procedure however has been simplified and may not work that easily. One of the reasons the lircd daemon may not be working is because it expects to be run at startup and needs root permissions because it will create device nodes in {{ic|/dev}}. Try "man lircd" for more information.<br />
<br />
Continue with [[#Making a configuration file]]<br />
<br />
=== Setup a HID device with LIRC ===<br />
Some remotes are supported in the kernel where they are treated as a keyboard and mouse. Every button on the device is recognized as keyboard or mouse events which can be used even without LIRC. LIRC can still be used with these devices to gain greater control over the events raised and integrate with programs that expect a LIRC remote rather than a keyboard. As drivers are migrated to the kernel, devices which use to only be useable through LIRC with their own {{ic|lirc.conf}} files become standard HID devices.<br />
<br />
Some HID remotes actually simulate a USB infrared keyboard and mouse. These remotes show up as two devices so you need to add two LIRC devices to {{ic|lircd.conf}}.<br />
<br />
First we need the {{ic|/dev/input}} device for our remote:<br />
<br />
$ ls /sys/class/rc/rc0<br />
<br />
One of the files should be input''#'', where the number matches the event''#'' of the device. (To clarify you can check that directory, it will have an event''#'' file.<br />
<br />
{{Note|If you have more than one ir device then there may be multiple directories under {{ic|/sys/class/rc}}. Under event''#'' {{ic|cat name}} to verify which device you are looking at.}}<br />
<br />
then go to {{ic|/dev/input/by-id}}<br />
<br />
$ ls -l /dev/input/by-id<br />
<br />
You should find a file that symlinks to the input''#'' above, and possibly others with a similar names for mouse events.<br />
<br />
lrwxrwxrwx 1 root root 9 10月 14 06:43 usb-3353_3713-event-if00 -> ../event9<br />
lrwxrwxrwx 1 root root 10 10月 14 06:43 usb-3353_3713-event-if01 -> ../event10<br />
<br />
Here 'usb-3353_3713-event-if00' and 'usb-3353_3713-event-if01' are the Linux input device event for our HID device, one for the keyboard, another for the mouse.<br />
<br />
Then, we need to edit {{ic|/etc/conf.d/lircd.conf}}. This file contains the parameters for LIRC daemon<br />
<br />
#<br />
#Parameters for daemon<br />
#<br />
<br />
LIRC_DEVICE="/dev/input/by-id/usb-3353_3713-event-if00"<br />
LIRC_DRIVER="devinput"<br />
LIRC_EXTRAOPS=""<br />
LIRC_CONFIGFILE="/etc/lirc/lircd.conf"<br />
<br />
{{Note|Here we set up a LIRC device with the id 3353_3713, you should replace it with your own device input event name, whatever it is.}}<br />
<br />
The latest version of the config file for HID remotes exists in the LIRC git repository [http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=blob_plain;f=remotes/devinput/lircd.conf.devinput;hb=HEAD]. Simply save it as {{ic|/etc/lirc/lircd.conf}}.<br />
<br />
In order to launch the LIRC daemon for HID remote, You must enable evdev module first<br />
# modprobe evdev<br />
<br />
{{Note|LIRC 0.8.6 has changed the default socket location from {{ic|/dev/lircd}} to {{ic|/var/run/lirc/lircd}}, but many applications still look for the socket in the old location. Since lirc-utils 0.8.6-3 the {{ic|/etc/rc.d/lircd}} script creates a symlink from {{ic|/dev/lircd}} to the {{ic|/var/run/lirc/lircd}} socket when it starts the lircd daemon and removes the link when the daemon is stopped.}}<br />
<br />
==Other receivers==<br />
<br />
There are many serial receivers that do not need any kernel module at all. Check the next link to see what kernel modules you need, if any:<br />
<br />
[http://www.lirc.org/html/table.html LIRC supported devices]<br />
<br />
==Checking module based receivers==<br />
<br />
''NOTE: This section only applies if your device requires a lirc_[driver] kernel module.''<br />
<br />
Before you start using lirc, you should check if your receiver is working, and if there is IR interference. Possible sources of interference include monitors/televisions (especially plasma displays), fluorescent lamps and direct or ambient sunlight. Start the following command to display raw receiver input.<br />
<br />
# mode2 -d /dev/lirc0 <br />
<br />
If you press buttons on any IR remote, you should see a series of pulses and spaces. If there is very frequent output without pressing buttons on your remote, your receiver suffers from interference. You want to avoid such interference, e.g. by placing the receiver behind or under your plasma tv.<br />
<br />
If you can't make out where the interference is coming from, you can try to put a cardboard roll right in front of the receiving diode, so that it only gets light from a specific direction. Invoke mode2 as above. Then point at different locations till you receive IR noise.<br />
<br />
==LIRC daemon configuration==<br />
<br />
The lircd configuration lives under /etc/conf.d/lircd.conf, and it is all you need to setup your device if it does not require any special kernel module.<br />
<br />
{{Box|IMPORTANT:|lirc-utils package on ArchLinux has a bug. You will have to create your own systemd unit or find another workaround. See [https://bugs.archlinux.org/task/31890 bug#31890] |#DF0000|#FFDFDF}}<br />
<br />
==Making a configuration file==<br />
<br />
You need a configuration file for your remote control copied or symlinked to {{ic|/etc/lirc/lircd.conf}}. A number of devices have already been included with the lirc package, they can be found in {{ic|/usr/share/lirc/remotes}}. If your specific device is not included, the LIRC site offers configuration files for a large number of extra [http://lirc.sourceforge.net/remotes/ devices].<br />
<br />
If your device does not already have a config file, you can create it yourself with the following command. You should avoid interference (see above) while creating the config file. <br />
<br />
# irrecord -d /dev/lirc0 /tmp/my_remote<br />
<br />
Just follow the instructions. To get a list of valid button names, refer to the output of<br />
# irrecord --list-namespace<br />
The resulting file, {{ic|/tmp/my_remote}}, should then be copied to {{ic|/etc/lirc/lircd.conf}}. If you want to use several remotes, you repeat the irrecord step with each remote and different filenames, and then concatenate all the resulting files into {{ic|/etc/lirc/lircd.conf}}:<br />
<br />
# cat /tmp/my_remote /tmp/my_remote2 /tmp/my_remote3 > /etc/lirc/lircd.conf<br />
<br />
{{Note|As of lirc-0.8.6 the default location of lircd, lircmd and lircrcd config files was moved to {{ic|/etc/lirc/lircd.conf}}, {{ic|/etc/lirc/lircmd.conf}} and {{ic|/etc/lirc/lircrc}}. If the config files are not found in that location, they are still searched at the old location in {{ic|/etc/.}}}}<br />
<br />
===Testing===<br />
<br />
First start the lircd daemon:<br />
<br />
# /etc/rc.d/lircd start<br />
<br />
A good way to see if LIRC is running is to run irw.<br />
<br />
$ irw<br />
<br />
When you press a button, you should see something like this:<br />
<br />
0000000000000001 00 play sony2<br />
0000000000000001 01 play sony2<br />
0000000000000001 02 play sony2<br />
0000000000000001 03 play sony2<br />
<br />
In this case the remote is called sony2, the button is called play, and LIRC has seen it 4 times.<br />
<br />
==Run LIRC at bootup==<br />
<br />
Remember if you had to execute the setserial command while [[LIRC#Loading|loading]] the module?<br />
<br />
If so, [[LIRC#Your serial port support is compiled into the kernel|your serial port support is compiled into the kernel]]<br />
<br />
===Your serial port support is compiled as a module in the kernel===<br />
<br />
This is rather easy: you will just have to add lirc_serial to the modules list and lircd to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
===Your serial port support is compiled into the kernel===<br />
<br />
This is more complicated, you cannot just add the lirc_serial to the modules list in {{ic|/etc/rc.conf}}, as the serial port should be released first.<br />
<br />
So I created a custom startup script to fix this problem.<br />
<br />
{{hc|/etc/rc.d/start_lirc|<nowiki><br />
#!/bin/bash<br />
#/etc/rc.d/start_lirc<br />
#releases ttySx and loads lirc_serial module<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy "release ttySx"<br />
setserial /dev/ttySx uart none<br />
#load lirc module<br />
modprobe lirc_serial<br />
stat_done<br />
;;<br />
stop)<br />
stat_busy "unload lirc module"<br />
rmmod lirc_serial<br />
stat_done<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now load the daemons: add "start_lirc" and "lircd" to the daemons list in {{ic|/etc/rc.conf}}<br />
<br />
==Program specific configuration==<br />
<br />
===Generate your own lircrc with Mythbuntu's lircrc-generator===<br />
<br />
'''mythbuntu-lircrc-generator''' is intended to be started from a system with LIRC installed. It requires that you choose a remote via the LIRC package or have a {{ic|lircd.conf}} handy prior to running. It will then produce a sane {{ic|.lircrc}} for the current user.<br />
<br />
[https://aur.archlinux.org/packages.php?ID=33849 Mythbuntu's Lirc/Lircrc Generator is available on AUR]<br/><br />
[http://manpages.ubuntu.com/manpages/intrepid/man1/mythbuntu-lirc-generator.1.html Man page]<br />
<br />
===Enable LIRC support in xine===<br />
<br />
Now LIRC works, but you have no program that can communicate with LIRC. This section will explain how to make xine work, but you can use xmms and mplayer (and probably a lot of other programs too) to work with LIRC.<br />
<br />
====Compile xine with LIRC support====<br />
Download the xine-ui PKGBUILD with [https://wiki.archlinux.org/index.php/Arch_Build_System ABS].<br />
<br />
Add " --enable-lirc" to the {{ic|./configure}} line<br />
<br />
Compile:<br />
<br />
$ makepkg<br />
<br />
Uninstall old xine-ui and install the new one<br />
<br />
# pacman -R xine-ui<br />
# pacman -U xine-filename.pkg.tar.gz<br />
<br />
====Configure xine to use LIRC====<br />
<br />
Let xine produce a default {{ic|.lircrc}} file. In your home directory, type:<br />
<br />
$ xine --keymap=lirc>.lircrc<br />
<br />
Now, in order to have a functioning xine+lirc, edit the {{ic|.lircrc}} file to your preferences.<br />
<br />
However, you may choose to configure LIRC to control more than just xine. If this is the case, you will need to manually edit the {{ic|.lircrc}} file, and add elements. <br />
<br />
Xine-ui<br />
Mplayer<br />
Totem<br />
Vlc<br />
Rhythmbox <br />
<br />
All work with LIRC, but you must enable LIRC support in the program in some cases, such as VLC. Simply copy the vlc packagebuild and edit it so that "--enable-lirc" is one of the compile options for VLC not FFMPEG!<br />
<br />
===Configure Amarok2 to use LIRC===<br />
<br />
Depending on your controller model, the following configuration works with Amarok2-svn. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##amarok2<br />
<br />
begin<br />
button = Play<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Play<br />
end<br />
<br />
begin<br />
button = Pause<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Pause<br />
end<br />
<br />
begin<br />
button = Stop<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Stop<br />
end<br />
<br />
begin<br />
button = Skip<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Next<br />
end<br />
<br />
begin<br />
button = Replay<br />
prog = irexec<br />
repeat = 0<br />
config = qdbus org.mpris.amarok /Player Prev<br />
end}}<br />
<br />
===Configure Audacious(2) to use LIRC===<br />
Depending on your controller model, the following configuration works with all versions of Audacious, including the mercurial builds. This configuration file will work with the MCEUSB controller.<br />
<br />
{{hc|~/.lircrc|2=##audacious<br />
<br />
begin<br />
prog = audacious<br />
button = Play<br />
config = PLAY<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Pause<br />
config = PAUSE<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Stop<br />
config = STOP<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Skip<br />
config = NEXT<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = Replay<br />
config = PREV<br />
repeat = 0<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolUp<br />
config = VOL_UP<br />
repeat = 1<br />
end<br />
<br />
begin<br />
prog = audacious<br />
button = VolDown<br />
config = VOL_DOWN<br />
repeat = 1<br />
end}}<br />
<br />
Additionally, there are other values that may be set according to the model set forth above. This was taken from the lirc.c file from audacious-plugins source code:<br />
<br />
{{hc|lirc.c|PLAY<br />
STOP<br />
PAUSE<br />
PLAYPAUSE<br />
NEXT<br />
PREV<br />
SHUFFLE<br />
REPEAT<br />
FWD<br />
BWD<br />
VOL_UP<br />
VOL_DOWN<br />
QUIT<br />
MUTE<br />
BAL_LEFT<br />
BAL_RIGHT<br />
BAL_CENTER<br />
LIST<br />
PLAYLIST_CLEAR<br />
PLAYLIST_ADD}}<br />
<br />
===Configure Mplayer to use LIRC===<br />
<br />
{{hc|~/.lircrc|2=##mplayer<br />
<br />
begin<br />
button = PLAY/PAUSE<br />
prog = mplayer<br />
config = pause<br />
repeat = 1<br />
end<br />
begin<br />
button = FWD<br />
prog = mplayer<br />
config = seek 5<br />
end<br />
begin<br />
button = REV<br />
prog = mplayer<br />
config = seek -5<br />
end<br />
begin<br />
button = MAXIMIZE<br />
prog = mplayer<br />
config = vo_fullscreen<br />
end<br />
}}<br />
<br />
only change PLAY/PAUSE, FWD etc. on keys from your /etc/lircd.conf<br />
<br />
==Device Specific Examples==<br />
=== X10 ===<br />
There is a dedicated wiki page with information about [[X10]]<br />
<br />
===Asus DH Deluxe series motherboard===<br />
Check the output of:<br />
{{bc|$ cat /dev/usb/hiddevX}}<br />
<br />
where X is 0,1 or bigger, and press some buttons on remote.<br />
If you can see reply, device works fine, follow steps:<br><br />
<br />
1. In file {{ic|/etc/conf.d/lircd.conf}} add:<br><br />
{{bc|1=LIRC_DRIVER="dvico"}}<br />
2. Reload LIRC: <br />
{{bc|/etc/rc.d/lircd restart}}<br />
<br />
===ASRock ION series (Nuvoton) quickstart===<br />
<br />
$ ln -s /usr/share/lirc/remotes/lirc_wb677/lircd.conf.wb677 /etc/lirc/lircd.conf<br />
$ /etc/rc.d/lircd restart<br />
<br />
===Streamzap PC Remote (USB)===<br />
{{Note|Xorg now auto recognizes this remote as a keybaord!}} <br />
To disable this behavior, add the following to {{ic|/etc/X11/xorg.conf.d/90-streamzap.conf}}:<br />
{{bc|Section "InputClass"<br />
Identifier "Ignore Streamzap IR"<br />
MatchProduct "Streamzap"<br />
MatchIsKeyboard "true"<br />
Option "Ignore" "true"<br />
EndSection}}<br />
<br />
#Install both packages (lirc lirc-utils)<br />
#Modprobe both kernel mods (lirc_dev and streamzap) (add these to your MODULES array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Create your {{ic|/etc/lirc/lircd.conf}} (for this remote, copy {{ic|/usr/share/lirc/remotes/streamzap/lircd.conf.streamzap}} to {{ic|/etc/lirc/lircd.conf}})<br />
#Start lircd via /etc/rc.d/lircd start (add lircd to your DAEMONS array in {{ic|/etc/rc.conf}} to survive a reboot)<br />
#Test the remote/lirc with irw<br />
<br />
$ irw<br />
00000000000028cc 00 CH_UP Streamzap_PC_Remote<br />
00000000000028ce 00 CH_DOWN Streamzap_PC_Remote<br />
00000000000028c8 00 8 Streamzap_PC_Remote<br />
00000000000028c5 00 5 Streamzap_PC_Remote<br />
00000000000028d2 00 OK Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d1 01 LEFT Streamzap_PC_Remote<br />
00000000000028d1 00 LEFT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d3 00 RIGHT Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
00000000000028d4 00 DOWN Streamzap_PC_Remote<br />
<br />
{{Note|When the batteries in this remote are low, it may stop working even though the red LED on the received still flashes when you hit buttons!}}<br />
<br />
<br />
=== Serial Port IR Receiver ===<br />
Here's how to get a "Home Brew" serial port IR receiver working:<br />
<br />
1. Create a udev rule to give non-privleged users read/write access to the serial port. I will be using ttyS0 in my example.<br />
{{hc|/etc/udev/rules.d/z98-serial.rules|<br />
# For serial port ttyS0 and LIRC<br />
KERNEL&#61;&#61;"ttyS0",SUBSYSTEM&#61;&#61;"tty",DRIVERS&#61;&#61;"serial",MODE&#61;"0666"}}<br />
<br />
2. Create the needed modprobe configs<br />
{{hc|/etc/modules-load.d/lirc_serial.conf|lirc_serial}}<br />
{{hc|/etc/modprobe.d/lirc_serial.conf|install lirc_serial /usr/bin/setserial /dev/ttyS0 uart none && /sbin/modprobe --first-time --ignore-install lirc_serial<br />
options lirc_serial type&#61;0<br />
remove lirc_serial /sbin/modprobe -r --first-time --ignore-remove lirc_serial && /sbin/modprobe -r lirc_dev}}<br />
{{Note|Using [[udev]] rules to run the setserial command does not work in my experience because lirc_serial gets loaded before the serial port rules are applied.}}<br />
<br />
3. Install your systemd service file.<br />
{{hc|/etc/systemd/system/lirc.service|[Unit]<br />
Description&#61;Linux Infrared Remote Control<br />
After&#61;network.target<br />
<br />
[Service]<br />
Type&#61;simple<br />
PIDFile&#61;/run/lirc/lircd.pid<br />
ExecStartPre&#61;/bin/rm -f /dev/lirc /dev/lircd /var/run/lirc/lircd<br />
ExecStart&#61;/usr/sbin/lircd -n -r -P /run/lirc/lircd.pid -d /dev/lirc0 -o /run/lirc/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /run/lirc/lircd /dev/lircd<br />
ExecStartPost&#61;/usr/bin/ln -sf /dev/lirc0 /dev/lirc<br />
ExecReload&#61;/bin/kill -SIGHUP $MAINPID<br />
<br />
[Install]<br />
WantedBy&#61;multi-user.target}}<br />
<br />
4. We still need the default tmpfiles to be created, so copy that config file to {{ic|/etc/tmpfiles.d/lirc.conf}}.<br />
{{bc|# cp -a /usr/lib/tmpfiles.d/lirc.conf /etc/tmpfiles.d/lirc.conf}}<br />
<br />
5. Create a {{ic|.lircrc}} file in your home directory for your user or a {{ic|/etc/lirc/lircrc}} file for system wide use.<br />
<br />
6. Have your service start at boot and then test with a reboot<br />
{{bc|1=# systemctl enable lirc.service<br />
# systemctl reboot}}<br />
<br />
or load the module and start the lirc.service.<br />
{{bc|# modprobe lirc_serial<br />
# systemctl start lirc.service}}<br />
<br />
==Troubleshooting==<br />
<br />
===Buttons processed several times when pressed===<br />
Problem in module ir_core which processes IR commands with LIRC at the same time. Simply blacklist it by creating the following file:<br />
<br />
{{hc|/etc/modprobe.d/remote_blacklist.conf|<br />
# Prevent processing button several times when pressed<br />
blacklist ir_core<br />
}}<br />
<br />
===After upgrading or installing Arch, an existing configuration stopped working===<br />
====Kernel module change====<br />
As of kernel 2.6.36, LIRC modules have been included in the kernel. Arch's ''lirc'' package has included the older kernel modules, which work with ''lircd'' without any additional configuration. However, a recent update removed those older modules, which results in the stock kernel modules being used. Unfortunately, these kernel modules treat the remote as a keyboard by default, which is incompatible for lircd. To correct this, put the following line to {{ic|/etc/rc.local}}:<br />
{{hc|/etc/rc.local|echo lirc > /sys/class/rc/rc0/protocols}}<br />
You may also run that command as root to enable LIRC for your current session.<br />
<br />
{{Note|It is also a good idea to remove the old LIRC kernel module from your MODULES array in {{ic|/etc/rc.conf}}, as it is no longer present.}}<br />
<br />
==See also==<br />
* http://www.mythtv.org/wiki/Category:Remote_Controls -- MythTV wiki main LIRC article<br />
* http://www.mythtv.org/wiki/MCE_Remote -- MythTV wiki on MCE remotes <br />
* http://en.gentoo-wiki.com/wiki/LIRC -- Gentoo wiki LIRC how-to<br />
* https://aur.archlinux.org/packages.php?ID=33849 -- Lirc/Lircrc Configuration Generator</div>Pajarohttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=179573Professional audio2012-01-22T09:47:50Z<p>Pajaro: talk about ladytray, a2j and suggest jack2 for multicore cpus</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Note|Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}}. The steps below are mostly to double-check that you have a working multimedia system.}}<br />
<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, try a '''period of 3'''. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use laditray instead. It is lightweight and with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the [https://aur.archlinux.org/packages/li/libffado-svn/libffado-svn.tar.gz development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{Package AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) /etc/asound.conf (system wide settings) to have these lines:<br />
<pre><br />
# convert alsa API over jack API<br />
# use it with<br />
# % aplay foo.wav<br />
<br />
# use this as default<br />
pcm.!default {<br />
type plug<br />
slave { pcm "jack" }<br />
}<br />
<br />
ctl.mixer0 {<br />
type hw<br />
card 1<br />
}<br />
<br />
# pcm type jack<br />
pcm.jack {<br />
type jack<br />
playback_ports {<br />
0 system:playback_1<br />
1 system:playback_2<br />
}<br />
capture_ports {<br />
0 system:capture_1<br />
1 system:capture_2<br />
}<br />
}</pre><br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''linux'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* {{Package AUR|linux-rt}}<br />
* {{Package AUR|linux-rt-ice}}<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Pajarohttps://wiki.archlinux.org/index.php?title=Bash/Prompt_customization&diff=174077Bash/Prompt customization2011-12-14T10:07:05Z<p>Pajaro: </p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Command shells (English)]]<br />
{{i18n|Color Bash Prompt}}<br />
<br />
There are a variety of possibilities for [[Bash]]'s prompt (PS1), and customizing it can help you be more productive at the command line. You can add additional information to your prompt, or you can simply add color to it to make the prompt stand out.<br />
<br />
==Basic prompts==<br />
The following settings are useful for distinguishing the root prompt from non-root users.<br />
<br />
*Edit Bash's personal configuration file:<br />
$ nano ~/.bashrc<br />
<br />
*Comment out the default prompt:<br />
#PS1='[\u@\h \W]\$ '<br />
<br />
*Add the following green prompt for regular users:<br />
<div style="font-family: monospace; white-space: pre; overflow: auto; margin: 1em 3em; padding: 1em; border: 3px solid #bcd; background-color: black; color: #aaa;"><span style="color: #0f0">[chiri@zetsubou ~]$</span> <span style="text-decoration: blink;">_</span></div><br />
PS1='\[\e[1;32m\][\u@\h \W]\$\[\e[0m\] '<br />
<br />
*Edit root's .bashrc file; copy it from /etc/skel if the file is not present:<br />
# nano /root/.bashrc<br />
*Assign a red prompt for root:<br />
<div style="font-family: monospace; white-space: pre; overflow: auto; margin: 1em 3em; padding: 1em; border: 3px solid #bcd; background-color: black; color: #aaa;"><span style="color: #f00">[root@zetsubou ~]#</span> <span style="text-decoration: blink;">_</span></div><br />
PS1='\[\e[1;31m\][\u@\h \W]\$\[\e[0m\] '<br />
<br />
===Slightly fancier prompts===<br />
*A green and blue prompt for regular users:<br />
<div style="font-family: monospace; white-space: pre; overflow: auto; margin: 1em 3em; padding: 1em; border: 3px solid #bcd; background-color: black; color: #aaa;"><span style="color: #0a0">chiri</span> <span style="color: #00f">~/docs</span> <span style="color: #0f0">$</span> echo "sample output text"<nowiki><br />
sample output text<br />
</nowiki><span style="color: #0a0">chiri</span> <span style="color: #00f">~/docs</span> <span style="color: #0f0">$</span> <span style="text-decoration: blink;">_</span></div><br />
PS1='\[\e[0;32m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[1;32m\]\$\[\e[m\] \[\e[1;37m\]'<br />
<br />
This will give a very pleasing, colorful prompt and theme for the console with bright white text.<br />
<br />
The string above contains color-set escape sequences (start coloring: \[\e[color\], end coloring: \[\e[m\]) and information placeholders:<br />
<br />
* \u - Username. The original prompt also has \h, which prints the host name.<br />
* \w - Current absolute path. Use \W for current relative path.<br />
* \$ - The prompt character (eg. '#' for root, '$' for regular users). <br />
<br />
The last color-set sequence, "\[\e[1;37m\]", is not closed, so the remaining text (everything typed into the terminal, program output and so on) will be in that (bright white) color. It may be desirable to change this color, or to delete the last escape sequence in order to leave the actual output in unaltered color. <br />
<br />
*A red and blue prompt for root:<br />
<div style="font-family: monospace; white-space: pre; overflow: auto; margin: 1em 3em; padding: 1em; border: 3px solid #bcd; background-color: black; color: #aaa;"><span style="color: #a00">root</span> <span style="color: #00f">~/docs</span> <span style="color: #a00">#</span> <span style="color: #0a0">echo "sample output text"<nowiki><br />
sample output text<br />
</nowiki></span><span style="color: #a00">root</span> <span style="color: #00f">~/docs</span> <span style="color: #a00">#</span> <span style="color: #0a0"><span style="text-decoration: blink;">_</span></span></div><br />
PS1='\[\e[0;31m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[0;31m\]\$ \[\e[m\]\[\e[0;32m\]'<br />
<br />
This will give you a red designation and green console text.<br />
<br />
==Advanced prompts==<br />
<br />
===Load/Mem Status for 256colors===<br />
This is not even pushing the limits. Other than using 'sed' to parse the memory and load average (using the ''-u'' option for non-buffering), and the builtin ''history'' to save your history to your ''HISTFILE'' after every command, which you may find incredibly useful when dealing with crashing shells or subshells, this is essentially just making BASH print variables it already knows, making this extremely fast compared to prompts with non-builtin commands.<br />
<br />
This prompt is from AskApache.com's [http://www.askapache.com/linux-unix/bash-power-prompt.html BASH Power Prompt article], which goes into greater detail. It is especially helpful for those wanting to understand 256 color terminals, ncurses, termcap, and terminfo.<br />
<br />
This is for '''256 color terminals''', which is where the '''\033[38;5;22m''' terminal escapes come from. <br />
{{bc|1=<br />
<span style="color:#0b0">802</span><span style="color:#005f00">/1024MB</span> <span style="color:#5f00af">1.28 1.20 1.13 3/94 18563</span><br />
<span style="color:#555">[5416:17880 0:70]</span> <span style="color:0bb">05:35:50 Wed Apr 21</span> <span style="color:#555">[</span><span style="color:#2b47ff">srot@host.sqpt.net</span><span style="color:#555">:</span><span style="color:#bbb">/dev/pts/0</span> <span style="color:#00bb00">+1</span><span style="color:#555">]</span> <span style="color:#000">~<br /><br />
(1:70)$ <span style="text-decoration: blink;">_</span></span><br />
}}<br />
<br />
PROMPT_COMMAND='history -a;echo -en "\033[m\033[38;5;2m"$(( `sed -nu "s/MemFree:[\t ]\+\([0-9]\+\) kB/\1/p" /proc/meminfo`/1024))"\033[38;5;22m/"$((`sed -nu "s/MemTotal:[\t ]\+\([0-9]\+\) kB/\1/Ip" /proc/meminfo`/1024 ))MB"\t\033[m\033[38;5;55m$(< /proc/loadavg)\033[m"'<br />
PS1='\[\e[m\n\e[1;30m\][$$:$PPID \j:\!\[\e[1;30m\]]\[\e[0;36m\] \T \d \[\e[1;30m\][\[\e[1;34m\]\u@\H\[\e[1;30m\]:\[\e[0;37m\]${SSH_TTY} \[\e[0;32m\]+${SHLVL}\[\e[1;30m\]] \[\e[1;37m\]\w\[\e[0;37m\] \n($SHLVL:\!)\$ '<br />
<br />
===List of colors for prompt and Bash===<br />
Add this to your Bash file(s) to define colors for prompt and commands:<br />
{{bc|<nowiki>txtblk='\e[0;30m' # Black - Regular<br />
txtred='\e[0;31m' # Red<br />
txtgrn='\e[0;32m' # Green<br />
txtylw='\e[0;33m' # Yellow<br />
txtblu='\e[0;34m' # Blue<br />
txtpur='\e[0;35m' # Purple<br />
txtcyn='\e[0;36m' # Cyan<br />
txtwht='\e[0;37m' # White<br />
bldblk='\e[1;30m' # Black - Bold<br />
bldred='\e[1;31m' # Red<br />
bldgrn='\e[1;32m' # Green<br />
bldylw='\e[1;33m' # Yellow<br />
bldblu='\e[1;34m' # Blue<br />
bldpur='\e[1;35m' # Purple<br />
bldcyn='\e[1;36m' # Cyan<br />
bldwht='\e[1;37m' # White<br />
unkblk='\e[4;30m' # Black - Underline<br />
undred='\e[4;31m' # Red<br />
undgrn='\e[4;32m' # Green<br />
undylw='\e[4;33m' # Yellow<br />
undblu='\e[4;34m' # Blue<br />
undpur='\e[4;35m' # Purple<br />
undcyn='\e[4;36m' # Cyan<br />
undwht='\e[4;37m' # White<br />
bakblk='\e[40m' # Black - Background<br />
bakred='\e[41m' # Red<br />
badgrn='\e[42m' # Green<br />
bakylw='\e[43m' # Yellow<br />
bakblu='\e[44m' # Blue<br />
bakpur='\e[45m' # Purple<br />
bakcyn='\e[46m' # Cyan<br />
bakwht='\e[47m' # White<br />
txtrst='\e[0m' # Text Reset</nowiki>}}<br />
<br />
<br/><br />
Or if you prefer color names you will know how to spell without a special decoder ring and want high intensity colors:<br />
{{bc|<nowiki># Reset<br />
Color_Off='\e[0m' # Text Reset<br />
<br />
# Regular Colors<br />
Black='\e[0;30m' # Black<br />
Red='\e[0;31m' # Red<br />
Green='\e[0;32m' # Green<br />
Yellow='\e[0;33m' # Yellow<br />
Blue='\e[0;34m' # Blue<br />
Purple='\e[0;35m' # Purple<br />
Cyan='\e[0;36m' # Cyan<br />
White='\e[0;37m' # White<br />
<br />
# Bold<br />
BBlack='\e[1;30m' # Black<br />
BRed='\e[1;31m' # Red<br />
BGreen='\e[1;32m' # Green<br />
BYellow='\e[1;33m' # Yellow<br />
BBlue='\e[1;34m' # Blue<br />
BPurple='\e[1;35m' # Purple<br />
BCyan='\e[1;36m' # Cyan<br />
BWhite='\e[1;37m' # White<br />
<br />
# Underline<br />
UBlack='\e[4;30m' # Black<br />
URed='\e[4;31m' # Red<br />
UGreen='\e[4;32m' # Green<br />
UYellow='\e[4;33m' # Yellow<br />
UBlue='\e[4;34m' # Blue<br />
UPurple='\e[4;35m' # Purple<br />
UCyan='\e[4;36m' # Cyan<br />
UWhite='\e[4;37m' # White<br />
<br />
# Background<br />
On_Black='\e[40m' # Black<br />
On_Red='\e[41m' # Red<br />
On_Green='\e[42m' # Green<br />
On_Yellow='\e[43m' # Yellow<br />
On_Blue='\e[44m' # Blue<br />
On_Purple='\e[45m' # Purple<br />
On_Cyan='\e[46m' # Cyan<br />
On_White='\e[47m' # White<br />
<br />
# High Intensty<br />
IBlack='\e[0;90m' # Black<br />
IRed='\e[0;91m' # Red<br />
IGreen='\e[0;92m' # Green<br />
IYellow='\e[0;93m' # Yellow<br />
IBlue='\e[0;94m' # Blue<br />
IPurple='\e[0;95m' # Purple<br />
ICyan='\e[0;96m' # Cyan<br />
IWhite='\e[0;97m' # White<br />
<br />
# Bold High Intensty<br />
BIBlack='\e[1;90m' # Black<br />
BIRed='\e[1;91m' # Red<br />
BIGreen='\e[1;92m' # Green<br />
BIYellow='\e[1;93m' # Yellow<br />
BIBlue='\e[1;94m' # Blue<br />
BIPurple='\e[1;95m' # Purple<br />
BICyan='\e[1;96m' # Cyan<br />
BIWhite='\e[1;97m' # White<br />
<br />
# High Intensty backgrounds<br />
On_IBlack='\e[0;100m' # Black<br />
On_IRed='\e[0;101m' # Red<br />
On_IGreen='\e[0;102m' # Green<br />
On_IYellow='\e[0;103m' # Yellow<br />
On_IBlue='\e[0;104m' # Blue<br />
On_IPurple='\e[10;95m' # Purple<br />
On_ICyan='\e[0;106m' # Cyan<br />
On_IWhite='\e[0;107m' # White<br />
</nowiki>}}<br />
<br />
To use in commands from your shell environment:<br />
$ echo -e "${txtblu}test"<br />
<font color='blue'>test</font><br />
$ echo -e "${bldblu}test"<br />
<font color='lightblue'><b>test</b></font><br />
$ echo -e "${undblu}test"<br />
<font color='lightblue'><b><u>test</u></b></font><br />
$ echo -e "${bakblu}test"<br />
<span style="color: white; background-color: lightblue"><b>test</b></span><br />
<br />
To use in a prompt (note double quotes and <nowiki>\[ \]</nowiki> used by the shell to count proper length):<br />
PS1="\[$txtblu\]foo\[$txtred\] bar\[$txtrst\] baz : "<br />
<br />
===Prompt escapes===<br />
The various Bash prompt escapes listed in the manpage:<br />
Bash allows these prompt strings to be customized by inserting a<br />
number of ''backslash-escaped special characters'' that are<br />
decoded as follows:<br />
<br />
\a an ASCII bell character (07)<br />
\d the date in "Weekday Month Date" format (e.g., "Tue May 26")<br />
\D{format} the format is passed to strftime(3) and the result<br />
is inserted into the prompt string an empty format<br />
results in a locale-specific time representation.<br />
The braces are required<br />
\e an ASCII escape character (033)<br />
\h the hostname up to the first `.'<br />
\H the hostname<br />
\j the number of jobs currently managed by the shell<br />
\l the basename of the shell's terminal device name<br />
\n newline<br />
\r carriage return<br />
\s the name of the shell, the basename of $0 (the portion following<br />
the final slash)<br />
\t the current time in 24-hour HH:MM:SS format<br />
\T the current time in 12-hour HH:MM:SS format<br />
\@ the current time in 12-hour am/pm format<br />
\A the current time in 24-hour HH:MM format<br />
\u the username of the current user<br />
\v the version of bash (e.g., 2.00)<br />
\V the release of bash, version + patch level (e.g., 2.00.0)<br />
\w the current working directory, with $HOME abbreviated with a tilde<br />
\W the basename of the current working directory, with $HOME<br />
abbreviated with a tilde<br />
\! the history number of this command<br />
\# the command number of this command<br />
\$ if the effective UID is 0, a #, otherwise a $<br />
\nnn the character corresponding to the octal number nnn<br />
\\ a backslash<br />
\[ begin a sequence of non-printing characters, which could be used<br />
to embed a terminal control sequence into the prompt<br />
\] end a sequence of non-printing characters<br />
<br />
The command number and the history number are usually different:<br />
the history number of a command is its position in the history<br />
list, which may include commands restored from the history file<br />
(see HISTORY below), while the command number is the position in<br />
the sequence of commands executed during the current shell session.<br />
After the string is decoded, it is expanded via parameter<br />
expansion, command substitution, arithmetic expansion, and quote<br />
removal, subject to the value of the promptvars shell option (see<br />
the description of the shopt command under SHELL BUILTIN COMMANDS<br />
below).<br />
<br />
===Positioning the cursor===<br />
The following sequence sets the cursor position:<br />
\[\033[<row>;<column>f\]<br />
<br />
The current cursor position can be saved using:<br />
\[\033[s\]<br />
<br />
To restore a position, use the following sequence: <br />
\[\033[u\]<br />
<br />
The following example uses these sequences to display the time in the upper right corner:<br />
PS1=">\[\033[s\]\[\033[1;\$((COLUMNS-4))f\]\$(date +%H:%M)\[\033[u\]"<br />
<br />
The environment variable ''COLUMNS'' contains the number of columns of the terminal. The above example substracts 4 from its value in order to justify the five character wide output of ''date'' at the right border.<br />
<br />
===Return value visualisation===<br />
<br />
WARNING WARNING WARNING WARNING<br><br />
This seemed to me to have some bugs, see the entry I added to the discussion page. You can add a \n after the smilie to avoid wrong line length calculation.<br />
<br />
Add this line if you want to see the return value of the last executed command. This should work with any kind of prompt as long as it does not need PROMPT_COMMAND:<br />
<nowiki>PROMPT_COMMAND='RET=$?; if [[ $RET -eq 0 ]]; then echo -ne "\033[0;32m$RET\033[0m ;)"; else echo -ne "\033[0;31m$RET\033[0m ;("; fi; echo -n " "'</nowiki><br />
<br />
It will look like this:<br />
<font color="green">0</font><b> ;) </b>harvie@harvie-ntb ~/ $ true<br />
<font color="green">0</font><b> ;) </b>harvie@harvie-ntb ~/ $ false<br />
<font color="red">1</font><b> ;( </b>harvie@harvie-ntb ~/ $ <br />
Zero is green and non-zero is red. There is also the smiley indication (replace it with anything you want); so your prompt will smile if the last operation was succesful.<br />
<br />
====Advanced return value visualisation====<br />
If you want colors, you need to set ''$RED'' and ''$GREEN'' values:<br />
RED='\e[0;31m'<br />
GREEN='\e[0;32m'<br />
<br />
You have to specify these values in Bash's configuration files:<br />
{{bc|<nowiki><br />
#return value visualisation<br />
PROMPT_COMMAND='RET=$?;'<br />
RET_VALUE='$(echo $RET)' #Ret value not colorized - you can modify it.<br />
RET_SMILEY='$(if [[ $RET = 0 ]]; then echo -ne "\[$GREEN\];)"; else echo -ne "\[$RED\];("; fi;)'<br />
</nowiki>}}<br />
<br />
Then you can use ''$RET_VALUE'' and ''$RET_SMILEY'' variables in the prompt. Note that you need use double quotes:<br />
#prompt<br />
PS1="$RET_VALUE $RET_SMILEY : "<br />
<br />
This will give you basic prompt:<br />
0 <font color="green">;)</font> : true<br />
0 <font color="green">;)</font> : false<br />
1 <font color="red">;(</font> : <br />
<br />
But you will probably want to use ''$RET_VALUE'' or ''$RET_SMILEY'' in your own prompt, like this:<br />
{{bc|<nowiki><br />
PS1="\[$WHITE\]$RET_VALUE $RET_SMILEY \[$BLUE\]\u\[$RED\]@\[$EBLUE\]\h\[$WHITE\] \W \[$ERED\]\\$\[$EWHITE\] "<br />
</nowiki>}}<br />
<br />
===Wolfman's===<br />
After reading through most of the [http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/index.html Bash Prompt Howto], the author developed a color bash prompt that displays the last 25 characters of the current working directory. This prompt should work well on terminals with a black background. The following code goes in file {{ic|~/.bashrc}}.<br />
<br />
*Add the bash_prompt_command function. If you have a couple directories with long names or start entering a lot of subdirectories, this function will keep the command prompt from wrapping around the screen by displaying at most the last pwdmaxlen characters from the PWD. This code was taken from the ''Bash Prompt Howto''<nowiki>'s</nowiki> section on [http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/x783.html Controlling the Size and Appearance of $PWD] and modified to replace the user's home directory with a tilde.<br />
##################################################<br />
# Fancy PWD display function<br />
##################################################<br />
# The home directory (HOME) is replaced with a ~<br />
# The last pwdmaxlen characters of the PWD are displayed<br />
# Leading partial directory names are striped off<br />
# /home/me/stuff -> ~/stuff if USER=me<br />
# /usr/share/big_dir_name -> ../share/big_dir_name if pwdmaxlen=20<br />
##################################################<br />
bash_prompt_command() {<br />
# How many characters of the $PWD should be kept<br />
local pwdmaxlen=25<br />
# Indicate that there has been dir truncation<br />
local trunc_symbol=".."<br />
local dir=${PWD##*/}<br />
pwdmaxlen=$(( ( pwdmaxlen < ${#dir} ) ? ${#dir} : pwdmaxlen ))<br />
NEW_PWD=${PWD/#$HOME/\~}<br />
local pwdoffset=$(( ${#NEW_PWD} - pwdmaxlen ))<br />
if [ ${pwdoffset} -gt "0" ]<br />
then<br />
NEW_PWD=${NEW_PWD:$pwdoffset:$pwdmaxlen}<br />
NEW_PWD=${trunc_symbol}/${NEW_PWD#*/}<br />
fi<br />
}<br />
<br />
*The next fragment generates the command prompt and various colors are defined. The user's color for the username, hostname, and prompt ($ or #) is set to cyan, and if the user is root (root's UID is always 0), set the color to red. The command prompt is set to a colored version of Arch's default with the NEW_PWD from the last function.<br />
<br />
:Also, make sure that your color variables are enclosed in double and not single quote marks. Using single quote marks seems to give Bash problems with line wrapping correctly.<br />
bash_prompt() {<br />
case $TERM in<br />
xterm*|rxvt*)<br />
local TITLEBAR='\[\033]0;\u:${NEW_PWD}\007\]'<br />
;;<br />
*)<br />
local TITLEBAR=""<br />
;;<br />
esac<br />
local NONE="\[\033[0m\]" # unsets color to term's fg color<br />
<br />
# regular colors<br />
local K="\[\033[0;30m\]" # black<br />
local R="\[\033[0;31m\]" # red<br />
local G="\[\033[0;32m\]" # green<br />
local Y="\[\033[0;33m\]" # yellow<br />
local B="\[\033[0;34m\]" # blue<br />
local M="\[\033[0;35m\]" # magenta<br />
local C="\[\033[0;36m\]" # cyan<br />
local W="\[\033[0;37m\]" # white<br />
<br />
# emphasized (bolded) colors<br />
local EMK="\[\033[1;30m\]"<br />
local EMR="\[\033[1;31m\]"<br />
local EMG="\[\033[1;32m\]"<br />
local EMY="\[\033[1;33m\]"<br />
local EMB="\[\033[1;34m\]"<br />
local EMM="\[\033[1;35m\]"<br />
local EMC="\[\033[1;36m\]"<br />
local EMW="\[\033[1;37m\]"<br />
<br />
# background colors<br />
local BGK="\[\033[40m\]"<br />
local BGR="\[\033[41m\]"<br />
local BGG="\[\033[42m\]"<br />
local BGY="\[\033[43m\]"<br />
local BGB="\[\033[44m\]"<br />
local BGM="\[\033[45m\]"<br />
local BGC="\[\033[46m\]"<br />
local BGW="\[\033[47m\]"<br />
<br />
local UC=$W # user's color<br />
[ $UID -eq "0" ] && UC=$R # root's color<br />
<br />
PS1="$TITLEBAR ${EMK}[${UC}\u${EMK}@${UC}\h ${EMB}\${NEW_PWD}${EMK}]${UC}\\$ ${NONE}"<br />
# without colors: PS1="[\u@\h \${NEW_PWD}]\\$ "<br />
# extra backslash in front of \$ to make bash colorize the prompt<br />
}<br />
<br />
*Finally, append this code. This ensures that the NEW_PWD variable will be updated when you cd somewhere else, and it sets the PS1 variable, which contains the command prompt.<br />
PROMPT_COMMAND=bash_prompt_command<br />
bash_prompt<br />
unset bash_prompt<br />
<br />
===KitchM's===<br />
These prompts offer a little more flash and visual clarity. Note that the use of red in the root user's prompt should provide ample warning. That is not to say someone could not use flashing text or arrow to do even more, but these will give you a good starting point.<br />
<br />
'''First''', change the default background in your terminal preferences (this example uses Xfce's Terminal program) to #D2D2D2, and the text color to #000000. The font is listed as DejaVu Sans Mono Book 12. The cursor color is #00AA00, and the tab activity color is #AF0000.<br />
<br />
'''Second''', in ~/.bashrc and right after the PS1= line, enter a new line with the following:<br />
PS1='\e[1;33;47m\u \e[1;32;47mon \h \e[1;35;47m\d \@\e[0;0m\n\e[1;34m[dir.= \w] \# > \e[0;0m'<br />
And then place a # in front of the first PS1 line to remark it out.<br />
<br />
'''Third''', for root user, edit /root/.bashrc in the same manner to include:<br />
PS1='\e[1;31;47m\u \e[1;32;47mon \h \e[1;35;47m\d \@\e[0;0m\n\e[1;31m[dir.= \w] \# > \e[0;0m'<br />
Do not forget to comment out the old line.<br />
<br />
These are double-line prompts, and they should look something like these:<br />
<br />
User-<br />
<span style="color:#D2D2D2; background:#D2D2D2"> </span><br />
<span style="color:#FFFF00; background:#A9A9A9"><b>Username</b></span><span style="color:#00FF00; background:#A9A9A9"><b> on myhost</b></span><span style="color:#FF00FF; background:#A9A9A9"><b> Sun Jan 15 12:30 PM</b></span><span style="color:#D2D2D2; background:#D2D2D2"> </span><br />
<span style="color:#0000FF; background:#D2D2D2"><b>[dir.= /home/username] 1 > </b> </span><br />
<span style="color:#D2D2D2; background:#D2D2D2"> </span><br />
<br />
Root-<br />
<span style="color:#D2D2D2; background:#D2D2D2"> </span><br />
<span style="color:#FF0000; background:#A9A9A9"><b>Root</b></span><span style="color:#00FF00; background:#A9A9A9"><b> on myhost</b> </span><span style="color:#FF00FF; background:#A9A9A9"><b> Sun Jan 15 12:30 PM</b> </span><span style="color:#D2D2D2; background:#D2D2D2"> </span> <br />
<span style="color:#FF0000; background:#D2D2D2"><b>[dir.= /etc/rc.d] 1 > </b> </span><br />
<span style="color:#D2D2D2; background:#D2D2D2"> </span><br />
<br />
You will note that the background colors make them easier to read, and the text colors just keep things interesting. There is a lot of leeway to make them personalized, just with the use of colors. Enjoy!<br />
<br />
==Set window title==<br />
[[Xterm]] and many other terminal emulators (including PuTTY) allow you to set the window title using special escape sequences. You can define the {{ic|<nowiki>${XTERM_TITLE}</nowiki>}} variable as follows, then insert it at the beginning of the prompt to set [[xterm]] title (if available) to directory@user@hostname:<br />
<br />
#set xterm title<br />
case "$TERM" in<br />
xterm | xterm-color)<br />
XTERM_TITLE='\[\e]0;\W@\u@\H\a\]'<br />
;;<br />
esac<br />
<br />
The text between {{ic|0;}} and {{ic|\a}} can be set to anything you like, for example:<br />
export PS1='\[\e]0;Welcome to ArchLinux\a\]\$>> '<br />
sets the window title to "Welcome to ArchLinux" and displays this simple prompt: <br />
{{bc|1=<br />
<span style="color: #000">$>></span> <span style="text-decoration: blink;">_</span><br />
}}<br />
<br />
==Different colors for text entry and console output==<br />
If you do not reset the text color at the end of your prompt, both the text you enter and the console text will simply stay in that color. If you want to edit text in a special color but still use the default color for command output, you will need to reset the color after you press enter, but still before any commands get run. You can do this by installing a DEBUG trap in your ~/.bashrc, like this:<br />
<br />
trap 'echo -ne "\e[0m"' DEBUG<br />
<br />
==Example bashrc from Gentoo==<br />
{{bc|<nowiki># /etc/bash.bashrc<br />
#<br />
# This file is sourced by all *interactive* bash shells on startup,<br />
# including some apparently interactive shells such as scp and rcp<br />
# that can't tolerate any output. So make sure this doesn't display<br />
# anything or bad things will happen !<br />
<br />
<br />
# Test for an interactive shell. There is no need to set anything<br />
# past this point for scp and rcp, and it's important to refrain from<br />
# outputting anything in those cases.<br />
<br />
if [[ $- != *i* ]] ; then<br />
# Shell is non-interactive. Be done now!<br />
return<br />
fi<br />
<br />
# Bash won't get SIGWINCH if another process is in the foreground.<br />
# Enable checkwinsize so that bash will check the terminal size when<br />
# it regains control. #65623<br />
# http://cnswww.cns.cwru.edu/~chet/bash/FAQ (E11)<br />
shopt -s checkwinsize<br />
<br />
# Enable history appending instead of overwriting. #139609<br />
shopt -s histappend<br />
<br />
# Change the window title of X terminals <br />
case ${TERM} in<br />
xterm*|rxvt*|Eterm|aterm|kterm|gnome*|interix)<br />
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"'<br />
;;<br />
screen)<br />
PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\033\\"'<br />
;;<br />
esac<br />
<br />
use_color=false<br />
<br />
# Set colorful PS1 only on colorful terminals.<br />
# dircolors --print-database uses its own built-in database<br />
# instead of using /etc/DIR_COLORS. Try to use the external file<br />
# first to take advantage of user additions. Use internal bash<br />
# globbing instead of external grep binary.<br />
safe_term=${TERM//[^[:alnum:]]/?} # sanitize TERM<br />
match_lhs=""<br />
[[ -f ~/.dir_colors ]] && match_lhs="${match_lhs}$(<~/.dir_colors)"<br />
[[ -f /etc/DIR_COLORS ]] && match_lhs="${match_lhs}$(</etc/DIR_COLORS)"<br />
[[ -z ${match_lhs} ]] \<br />
&& type -P dircolors >/dev/null \<br />
&& match_lhs=$(dircolors --print-database)<br />
[[ $'\n'${match_lhs} == *$'\n'"TERM "${safe_term}* ]] && use_color=true<br />
<br />
if ${use_color} ; then<br />
# Enable colors for ls, etc. Prefer ~/.dir_colors #64489<br />
if type -P dircolors >/dev/null ; then<br />
if [[ -f ~/.dir_colors ]] ; then<br />
eval $(dircolors -b ~/.dir_colors)<br />
elif [[ -f /etc/DIR_COLORS ]] ; then<br />
eval $(dircolors -b /etc/DIR_COLORS)<br />
fi<br />
fi<br />
<br />
if [[ ${EUID} == 0 ]] ; then<br />
PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] '<br />
else<br />
PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '<br />
fi<br />
<br />
alias ls='ls --color=auto'<br />
alias grep='grep --colour=auto'<br />
else<br />
if [[ ${EUID} == 0 ]] ; then<br />
# show root@ when we do not have colors<br />
PS1='\u@\h \W \$ '<br />
else<br />
PS1='\u@\h \w \$ '<br />
fi<br />
fi<br />
<br />
# Try to keep environment pollution down, EPA loves us.<br />
unset use_color safe_term match_lhs</nowiki>}}<br />
<br />
==See also==<br />
* [http://aur.archlinux.org/packages.php?ID=18418 gentoo-bashrc] from [[AUR]]<br />
* tput(1)<br />
* [http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x405.html Colours and Cursor Movement With tput]<br />
<br />
==External links==<br />
* Forum Discussions:<br />
** [http://bbs.archlinux.org/viewtopic.php?id=1817 BASH prompt]<br />
** [http://bbs.archlinux.org/viewtopic.php?id=50885 What's your PS1?]<br />
* http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/x329.html<br />
* [http://gilesorr.com/bashprompt/prompts/index.html Giles Orr's collection of sample prompts]</div>Pajarohttps://wiki.archlinux.org/index.php?title=AUR_helpers&diff=138573AUR helpers2011-04-27T06:02:59Z<p>Pajaro: </p>
<hr />
<div>[[Category:Utilities (English)]]<br />
[[Category:AUR (English)]]<br />
[[Category:Package management (English)]]<br />
This is a list of helper utilities that search and/or build packages from the [[Arch User Repository]].<br />
<br />
{{Warning|None of these tools are officially supported by Arch devs. See [https://bbs.archlinux.org/viewtopic.php?pid&#61;828254#p828254].}}<br />
<br />
A list of graphical pacman front-ends, some of which also work with the AUR, may be found at [[pacman GUI Frontends]].<br />
<br />
== List of Helpers ==<br />
=== arson ===<br />
<br />
Arson is an AUR searcher and downloader, written in Ruby. It allows you to search the AUR for a package you want, and download it. It does NOT automatically install the downloaded package. It can extract it, but not install. Searching for a package also searches through pacman's database cache (rather than going to each mirror and querying those).<br />
<br />
* Website: http://evaryont.github.com/arson<br />
* Forum: https://bbs.archlinux.org/viewtopic.php?id=46201<br />
* Package: http://aur.archlinux.org/packages.php?ID=16021<br />
<br />
=== aurbuild ===<br />
<br />
aurbuild is a tool to download and build packages from the AUR.<br />
<br />
*Website: http://aurbuild.berlios.de/<br />
*Package: http://aur.archlinux.org/packages.php?ID=1775<br />
<br />
=== aurget ===<br />
<br />
Aurget aims to be a simple, pacman-like interface to the AUR. It tries to make the AUR convenient; whether the user wishes to find, download, build, install, or update AUR packages quickly. Aurget does not wrap any pure pacman commands, this is by design.<br />
<br />
*Website: http://pbrisbin.com/posts/aurget/<br />
*Package: http://aur.archlinux.org/packages.php?ID=31933<br />
<br />
=== aurora ===<br />
<br />
Aurora is a very simple frontend for the AUR written in python3. It allows the user to install AUR packages, download the AUR packages (for manual installation) and also offers an AUR upgrade feature. By design, aurora does not wrap pacman.<br />
<br />
*Website: http://bitbucket.org/bbenne10/aurora<br />
*Package: http://aur.archlinux.org/packages.php?ID=41732<br />
<br />
=== aurpac ===<br />
<br />
Light'n'fast AUR and pacman frontend.<br />
<br />
*Website: http://3ed.jogger.pl/2009/02/15/aurpac/<br />
*Package: http://aur.archlinux.org/packages.php?ID=23919<br />
<br />
=== aurploader ===<br />
<br />
Aurploader prompts the user for an AUR username and password and will then upload PKGBUILD tarballs to the AUR. Before uploading each package, the user is prompted to select a category. When the uploads have completed, the user is asked if the cookie file should be kept so that the script can be run again without needing the AUR username and password to be re-entered.<br />
<br />
*Website: http://xyne.archlinux.ca/info/aurploader<br />
*Package: http://aur.archlinux.org/packages.php?ID=23393<br />
<br />
=== aursh ===<br />
<br />
AurShell is a shell like application written in Python. With plugins included, it's possible to build and install packages from AUR, ABS, and even wrap pacman.<br />
<br />
*Website: http://github.com/husio/aursh/<br />
*Package: http://aur.archlinux.org/packages.php?ID=33423<br />
<br />
=== autoaur ===<br />
<br />
autoaur is a script for automatic mass downloading, updating, building, and installing groups of AUR packages.<br />
<br />
*Website: http://wiki.archlinux.org/index.php/autoaur<br />
*Package: http://aur.archlinux.org/packages.php?ID=6390<br />
<br />
=== bauerbill ===<br />
{{Warning|''Bauerbill'' development has been officially discontinued: its latest version does not work with ''pacman>&#61;3.5''. See [https://bbs.archlinux.org/viewtopic.php?id&#61;115660].}}<br />
[[Bauerbill]] is an extension of [[Powerpill]] that supports downloading and building packages from ABS, the AUR, CPAN and Hackage. It supports download acceleration via parallel and segmented downloads, including for source files when building packages.<br />
<br />
*Website: http://xyne.archlinux.ca/old_projects/bauerbill<br />
<br />
=== burp ===<br />
<br />
burp is a fast and simple AUR uploader written in C. Supports persistent cookies for seamless logins.<br />
<br />
*Website: http://github.com/falconindy/burp<br />
*Package: http://aur.archlinux.org/packages.php?ID=37216<br />
<br />
=== clyde ===<br />
<br />
[[Clyde]] is a next-generation libalpm/makepkg wrapper with AUR support, multithreaded downloading, and colorized output.<br />
<br />
* Website: https://github.com/Kiwi/clyde<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?id=91860<br />
* Package: http://aur.archlinux.org/packages.php?ID=34686<br />
<br />
=== cower ===<br />
<br />
Cower is a fast and simple AUR search and download agent, which will also check for updates and download dependencies. Written in C.<br />
<br />
*Website: http://github.com/falconindy/cower<br />
*Forum: https://bbs.archlinux.org/viewtopic.php?id=97137<br />
*Package: http://aur.archlinux.org/packages.php?ID=44921<br />
<br />
=== haskell-archlinux ===<br />
<br />
haskell-archlinux is a library to programmatically access the AUR and package metadata from the Haskell programming language.<br />
<br />
*Website: http://hackage.haskell.org/package/archlinux<br />
*Package: http://aur.archlinux.org/packages.php?ID=29267<br />
<br />
=== makeaur ===<br />
<br />
Makeaur is a wrapper for pacman and makepkg that allows users to easily install packages from the Arch User Repository.<br />
<br />
*Website: http://github.com/ghost1227/makeaur/<br />
*Package: http://aur.archlinux.org/packages.php?ID=23678<br />
<br />
=== makerepo ===<br />
{{Warning|''Makerepo'' development has been officially discontinued: its latest version does not work with ''pacman>&#61;3.5''. See [https://bbs.archlinux.org/viewtopic.php?id&#61;115660].}}<br />
<br />
Makerepo is a tool to simplify building and maintaining a repository. A simple configuration file is used to specify the basic arguments such as database name and directory, package lists, etc. Makerepo is able to build packages from the AUR and from local PKGBUILDs such as the ABS tree. It can even build packages from CPAN modules if pacpan is installed.<br />
<br />
*Website: http://xyne.archlinux.ca/old_projects/makerepo<br />
<br />
=== packer ===<br />
<br />
Packer is a bash wrapper for pacman and the AUR. It was designed to be a simple and very fast replacement for the basic functionality of Yaourt. It has commands to install, update, search, and show information for any package in the main repositories and in the AUR. Use pacman for other commands, such as removing a package. It is fully functional.<br />
<br />
* Website: http://github.com/bruenig/packer<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?id=88115<br />
* Package: http://aur.archlinux.org/packages.php?ID=33378<br />
<br />
=== pacmoon ===<br />
<br />
pacmoon is a script for compiling arch linux packages from the AUR and repositories. It can automatically install make dependencies as binaries when necessary and update the entire system or just packages listed. It keeps track of which files have been compiled so that in the event of compiled packages getting replaced with a binary (like during an upgrade process) then pacmoon can recompile only the necessary packages.<br />
<br />
*Website: http://chilon.net/pacmoon<br />
*Package: http://aur.archlinux.org/packages.php?ID=41911<br />
<br />
=== paktahn ===<br />
<br />
Paktahn is a yaourt replacement written from the ground-up using Lisp. It is under active development and already includes improvements such as a local cache for fast searches and interactive installation.<br />
<br />
* Website: http://github.com/skypher/paktahn<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?id=77674&p=1<br />
* Package: http://aur.archlinux.org/packages.php?ID=30242<br />
<br />
=== pbfetch ===<br />
<br />
Pbfetch is a script which can be used as a pacman-independent AUR helper or a pacman wrapper with additional AUR functionality. Pbfetch aims to be a simple and fast versus the well established yaourt.<br />
Pbfetch can be used as a shortcut to simply download PKGBUILDs from AUR or automatically build with dependency resolution among other things. The user can select which AUR packages to upgrade using a simple menu as well as update all AUR packages.<br />
<br />
*Website/Source: https://github.com/dalingrin/pbfetch<br />
*Forum: https://bbs.archlinux.org/viewtopic.php?id=87789<br />
*Package: http://aur.archlinux.org/packages.php?ID=33256<br />
<br />
=== pbget ===<br />
<br />
Pbget is a simple command-line tool for retrieving PKGBUILDs and local source files for Arch Linux. It is able to retrieve files from the official SVN and CVS web interface, the AUR and the ABS rsync server.<br />
<br />
*Website: http://xyne.archlinux.ca/info/pbget<br />
*Package: http://aur.archlinux.org/packages.php?ID=23848<br />
<br />
=== pkgman ===<br />
<br />
pkgman is a bash script which helps to manage a local repository. It retrieves the PKGBUILD and related files for given name from ABS or AUR and lets you edit them, automatically generates checksums, backs up the source tarball, builds and adds the package to your local repository. Then you can install it as usual with pacman. It also has AUR support for submitting tarballs and leaving comments.<br />
<br />
* Website: http://sourceforge.net/apps/mediawiki/pkgman/index.php<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?id=49023<br />
* Package: http://aur.archlinux.org/packages.php?ID=17100<br />
<br />
=== qpkg ===<br />
<br />
qpkg is a tool written in python for searching in all known repositories and on AUR. It can install and automatically update packages from AUR and it also can install all needed dependencies of a package from AUR.<br />
<br />
*Website: http://qpkg.berlios.de/<br />
*Package: http://developer.berlios.de/project/showfiles.php?group_id=4501<br />
<br />
=== slurpy ===<br />
<br />
{{Warning|''Slurpy'' development has been officially discontinued. See [http://rsontech.net/articles/2011/02/20/21/projects-removed].}}<br />
<br />
slurpy is an AUR helper written in python for searching AUR, downloading packages, showing information about packages, checking for updates and uploading a package to AUR. <br />
<br />
* Website: http://rsontech.net/projects/slurpy/<br />
* Forum: https://bbs.archlinux.org/viewtopic.php?id=75984<br />
* Package: http://aur.archlinux.org/packages.php?ID=28285<br />
<br />
=== spinach ===<br />
<br />
Spinach is a tiny Bash AUR helper with few dependencies.<br />
<br />
*Website: http://floft.net/wiki/Scripts/Spinach<br />
*Package: http://aur.archlinux.org/packages.php?ID=46993<br />
<br />
=== srcman ===<br />
<br />
srcman is a pacman/makepkg wrapper written in Bash, which transparently handles pacman operations on 'source packages'. This means, for example, that packages can be specified for installation either explicitly (pacman's -U operation) or can be installed from a (source) repository (-S operation). The address of an AUR pacman database can be found in the corresponding forum thread, by the way.<br />
The primary goal of this project is to provide a complete pacman wrapper and therefore, srcman supports all current pacman operations for binary ''and'' source packages.<br />
<br />
*Website: http://bbs.archlinux.org/viewtopic.php?id=65501<br />
*Package: http://aur.archlinux.org/packages.php?ID=23945<br />
<br />
=== tupac ===<br />
<br />
tupac is a pacman/yaourt wrapper written in PHP. The main difference between tupac and the rest of tupac wrappers is that it caches the local package database, so it gives you really fast operatibility even in environments with low resources (low RAM, slow disks). It also gives you two advanced features: checking for missing installed files and checking for files that are not owned by any package.<br />
<br />
*Package: http://aur.archlinux.org/packages.php?ID=13322<br />
<br />
=== yaourt ===<br />
<br />
[[Yaourt]] (Yet Another User Repository Tool) is a community-contributed wrapper for pacman which adds seamless access to the AUR, allowing and automating package compilation and installation from your choice of the thousands of PKGBUILDs in the AUR, in addition to the many thousands of available Arch binary packages. Yaourt uses the same exact syntax as pacman, which saves you from relearning an entirely new method of system maintenance, but also adds new options. Yaourt expands the power and simplicity of pacman by adding even more useful features and provides pleasing, colorized output, interactive search mode, and much more.<br />
<br />
*Website: http://archlinux.fr/yaourt-en<br />
*Package: http://aur.archlinux.org/packages.php?ID=5863<br />
<br />
== Comparison Table ==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
! Program !! Written in !! Dependency Support !! Core/extra/community support !! Actively Developed !! Usage <br />
|-<br />
! [[#aurget|Aurget]]<br />
| Bash || Yes || No || Yes || see <tt>aurget --help</tt><br />
|-<br />
! [[#aursh|AurShell]]<br />
| Python || No || No || Yes, as aursh || aursh (runs Aurshell program, wherein a number of different commands can be used)<br />
|-<br />
! [[#aurora|Aurora]]<br />
| Python3 || Basic (with makepkg) || No || Yes || see aurora --help<br />
|-<br />
! [[#bauerbill|Bauerbill]]<br />
| Perl || Yes || Yes || No || Identical to pacman (e.g., bauerbill -S <pkgname>)<br />
|-<br />
! [[#clyde|Clyde]]<br />
| Lua|| Yes || Yes || Yes || Identical to pacman (e.g., clyde -S <pkgname>)<br />
|-<br />
! [[#cower|Cower]]<br />
| C|| Yes || No || Yes || see <tt>cower -h</tt><br />
|-<br />
! [[#makeaur|Makeaur]]<br />
| Bash || No || No || Has been forked || makeaur <pkgname> <br />
|-<br />
! [[#packer|Packer]]<br />
| Bash || Yes || Yes || Yes || Identical to pacman (e.g., packer -S <pkgname>)<br />
|-<br />
! [[#pacmoon|pacmoon]]<br />
| Zsh|| Yes || Yes || Yes || Similar to emerge from portage e.g. pacmoon -av <pkgname><br />
|-<br />
! [[#paktahn|Paktahn]]<br />
| Lisp|| Yes || Yes || Yes || Identical to pacman (e.g., pak -S <pkgname>)<br />
|-<br />
! [[#pbfetch|pbfetch]]<br />
| Bash || Yes || Yes || Yes || Identical to pacman, and/or AUR specifc arguments (additional arguments for PKGBUILD editing, etc)<br />
|-<br />
! [[#tupac|tupac]]<br />
| PHP || Yes || Yes || Updated under request || Identical to pacman (e.g., tupac -S <pkgname>)<br />
|-<br />
! [[#yaourt|Yaourt]]<br />
| Bash, back-end in C || Yes || Yes || Yes || Identical to pacman (e.g., yaourt -S <pkgname>)<br />
|}</div>Pajarohttps://wiki.archlinux.org/index.php?title=AUR_helpers&diff=101591AUR helpers2010-03-31T07:15:16Z<p>Pajaro: </p>
<hr />
<div>[[Category:Utilities (English)]]<br />
[[Category:AUR (English)]]<br />
[[Category:Package management (English)]]<br />
This is a list of helper utilities that search and/or build packages from the [[Arch User Repository]]. '''None of these tools are officially supported.'''<br />
<br />
A list of graphical pacman front-ends, some of which also work with the AUR, may be found at [[pacman GUI Frontends]].<br />
<br />
== arson ==<br />
<br />
Arson is an AUR searcher and downloader, written in Ruby. It allows you to search the AUR for a package you want, and download it. It does NOT automatically install the downloaded package. It can extract it, but not install. Searching for a package also searches through pacman's database cache (rather than going to each mirror and querying those).<br />
<br />
*Website: http://evaryont.github.com/arson/<br />
*Package: http://aur.archlinux.org/packages.php?ID=16021<br />
<br />
== aurbuild ==<br />
<br />
aurbuild is a tool to download and build packages from the AUR.<br />
<br />
*Website: http://aurbuild.berlios.de/<br />
*Package: http://aur.archlinux.org/packages.php?ID=1775<br />
<br />
== aurget ==<br />
<br />
Aurget aims to be a simple, pacman-like interface to the AUR. It tries to make the AUR convenient; whether the user wishes to find, download, build, install, or update AUR packages quickly.<br />
<br />
*Website: http://pbrisbin.com:8080/pages/aurget.html<br />
*Package: http://aur.archlinux.org/packages.php?ID=31933<br />
<br />
== aurpac ==<br />
<br />
Light'n'fast AUR and pacman frontend.<br />
<br />
*Website: http://3ed.jogger.pl/2009/02/15/aurpac/<br />
*Package: http://aur.archlinux.org/packages.php?ID=23919<br />
<br />
== aurploader ==<br />
<br />
Aurploader prompts the user for an AUR username and password and will then upload PKGBUILD tarballs to the AUR. Before uploading each package, the user is prompted to select a category. When the uploads have completed, the user is asked if the cookie file should be kept so that the script can be run again without needing the AUR username and password to be re-entered.<br />
<br />
*Website: http://xyne.archlinux.ca/info/aurploader<br />
*Package: http://aur.archlinux.org/packages.php?ID=23393<br />
<br />
== aursh ==<br />
<br />
AurShell is a shell like application written in Python. With plugins included, it's possible to build and install packages from AUR, ABS, and even wrap pacman.<br />
<br />
*Website: http://github.com/husio/aursh/<br />
*Package: http://aur.archlinux.org/packages.php?ID=33423<br />
<br />
== autoaur ==<br />
<br />
[[autoaur]] is a script for automatic mass downloading, updating, building, and installing groups of AUR packages.<br />
<br />
*Website: http://wiki.archlinux.org/index.php/autoaur<br />
*Package: http://aur.archlinux.org/packages.php?ID=6390<br />
<br />
== clyde ==<br />
<br />
Clyde is a next-generation libalpm/makepkg wrapper with AUR support, multithreaded downloading, and colorized output.<br />
<br />
*Website: http://clyde.archuser.com/ (Forum: http://bbs.archlinux.org/viewtopic.php?id=91860)<br />
*Package: http://aur.archlinux.org/packages.php?ID=34686<br />
<br />
== haskell-archlinux ==<br />
<br />
haskell-archlinux is a library to programmatically access the AUR and package metadata from the Haskell programming language.<br />
<br />
*Website: http://hackage.haskell.org/package/archlinux<br />
*Package: http://aur.archlinux.org/packages.php?ID=29267<br />
<br />
== makeaur ==<br />
<br />
Makeaur is a wrapper for pacman and makepkg that allows users to easily install packages from the Arch User Repository.<br />
<br />
*Website: http://github.com/ghost1227/makeaur/<br />
*Package: http://aur.archlinux.org/packages.php?ID=23678<br />
<br />
== makerepo ==<br />
<br />
Makerepo is a tool to simplify building and maintaining a repository. A simple configuration file is use to specify the basic arguments such as database name and directory, package lists, etc. Makerepo is able to build packages from the AUR and from local PKGBUILDs such as the ABS tree. It can even build packages from CPAN modules if pacpan is installed.<br />
<br />
*Website: http://xyne.archlinux.ca/info/makerepo<br />
*Package: http://aur.archlinux.org/packages.php?ID=23500<br />
<br />
== packer ==<br />
<br />
Packer is a bash wrapper for pacman and the AUR. It was designed to be a simple and very fast replacement for the basic functionality of Yaourt. It has commands to install, update, search, and show information for any package in the main repositories and in the AUR. Use pacman for other commands, such as removing a package. It is fully functional.<br />
<br />
*Website: http://github.com/bruenig/packer (Forum: http://bbs.archlinux.org/viewtopic.php?id=88115)<br />
*Package: http://aur.archlinux.org/packages.php?ID=33378<br />
<br />
== pbget ==<br />
<br />
Pbget is a simple command-line tool for retrieving PKGBUILDs and local source files for Arch Linux. It is able to retrieve files from the official SVN and CVS web interface, the AUR and the ABS rsync server.<br />
<br />
*Website: http://xyne.archlinux.ca/info/pbget<br />
*Package: http://aur.archlinux.org/packages.php?ID=23848<br />
<br />
== pkgman ==<br />
<br />
pkgman is a bash script which helps to manage a local repository. It retrieves the PKGBUILD and related files for given name from ABS or AUR and lets you edit them, automatically generates checksums, backs up the source tarball, builds and adds the package to your local repository. Then you can install it as usual with pacman. It also has AUR support for submitting tarballs and leaving comments.<br />
<br />
*Website: http://sourceforge.net/apps/mediawiki/pkgman/index.php (Forum: http://bbs.archlinux.org/viewtopic.php?id=49023)<br />
*Package: http://aur.archlinux.org/packages.php?ID=17100<br />
<br />
== qpkg ==<br />
<br />
qpkg is a tool written in python for searching in all known repositories and on AUR. It can install and automatically update packages from AUR and it also can install all needed dependencies of a package from AUR.<br />
<br />
*Website: http://qpkg.berlios.de/<br />
*Package: ??? (seriously?)<br />
<br />
== slurpy ==<br />
<br />
slurpy is an AUR helper written in python for searching AUR, downloading packages, showing information about packages, checking for updates and uploading a package to AUR. <br />
<br />
*Website: http://rsontech.net/projects/slurpy/<br />
*Package: http://aur.archlinux.org/packages.php?ID=28285<br />
<br />
== srcman ==<br />
<br />
srcman is a pacman/makepkg wrapper written in Bash, which transparently handles pacman operations on 'source packages'. This means, for example, that packages can be specified for installation either explicitly (pacman's -U operation) or can be installed from a (source) repository (-S operation). The address of an AUR pacman database can be found in the corresponding forum thread, by the way.<br />
The primary goal of this project is to provide a complete pacman wrapper and therefore, srcman supports all current pacman operations for binary ''and'' source packages.<br />
<br />
*Website: http://bbs.archlinux.org/viewtopic.php?id=65501<br />
*Package: http://aur.archlinux.org/packages.php?ID=23945<br />
<br />
== tupac ==<br />
<br />
tupac is a pacman/yaourt wrapper written in PHP. The main difference between tupac and the rest of tupac wrappers is that it caches the local package database, so it gives you really fast operatibility even in environments with low resources (low RAM, slow disks). It also gives you two advanced features: checking for missing installed files and checking for files that are not owned by any package.<br />
<br />
*Package: http://aur.archlinux.org/packages.php?ID=13322<br />
<br />
== yaourt ==<br />
<br />
[[Yaourt]] (Yet Another User Repository Tool) is a community-contributed wrapper for pacman which adds seamless access to the AUR, allowing and automating package compilation and installation from your choice of the thousands of PKGBUILDs in the AUR, in addition to the many thousands of available Arch binary packages. Yaourt uses the same exact syntax as pacman, which saves you from relearning an entirely new method of system maintenance, but also adds new options. Yaourt expands the power and simplicity of pacman by adding even more useful features and provides pleasing, colorized output, interactive search mode, and much more.<br />
<br />
*Website: http://archlinux.fr/yaourt-en<br />
*Package: http://aur.archlinux.org/packages.php?ID=5863<br />
<br />
== yogurt ==<br />
<br />
Yogurt is a tool used for building packages for unsupported software which is only provided by PKGBUILDs in the Arch Linux User Repository. Yogurt features rudimentary dependency support both for standard repositories and the AUR.<br />
<br />
*Website: http://wikilinux.altervista.org/dokuwiki/doku.php?id=scriptseprogrammi:yogurt<br />
*Package: http://aur.archlinux.org/packages.php?ID=5863</div>Pajarohttps://wiki.archlinux.org/index.php?title=Ext3&diff=22507Ext32007-04-02T10:37:12Z<p>Pajaro: </p>
<hr />
<div>[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Copyright==<br />
Copyright (c) 2005 Peter Gordon (codergeek42)<br />
<br />
Permission is granted to copy, distribute and/or modify this document<br />
under the terms of the GNU Free Documentation License, Version 1.2<br />
or any later version published by the Free Software Foundation;<br />
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover<br />
Texts. <br />
<br />
==Overview==<br />
<br />
I'm a big fan of the Third Extended ("ext3") filesystem. It's in-kernel and userspace code has been tried, tested, fixed, and improved upon more than almost every other Linux-compatible filesystem. It's simple, robust, and extensible. In this article I intend to explain some tips that can improve both the performance and the reliability of the filesystem.<br />
<br />
In the document, /dev/hdXY will be used as a generic partition. You should replace this with the actual device node for your partition, such as /dev/hdb1 for the first partition of the primary slave disk or /dev/sda2 for the second partition of your first SCSI or Serial ATA disk.<br />
<br />
==Using The tune2fs and e2fsck Utilities==<br />
<br />
Before we begin, we need to make sure you are comfortable with using the tune2fs utility to alter the filesystem options of an ext2 or ext3 partition. Please make sure to read the tune2fs man page:<br />
<br />
$ man tune2fs<br />
It's generally a good idea to run a filesystem check using the e2fsck utility after you've completed the alterations you wish to make on your filesystem. This will verify that your filesystem is clean and fix it if needed. You should also read the manual page for the e2fsck utility if you have not yet done so:<br />
<br />
$ man e2fsck<br />
<br />
'''WARNING: ONLY RUN UNMOUNTED:''' Make sure any filesystems are cleanly unmounted before altering them with the tune2fs or e2fsck utilities! (Boot from a LiveCD such as '''Archie''' or Knoppix if you need to.) Altering or tuning a filesystem while it is mounted can cause severe corruption! You have been warned!<br />
<br />
==Using Directory Indexing==<br />
<br />
This feature improves file access in large directories or directories containing many files by using hashed binary trees to store the directory information. It's perfectly safe to use, and it provides a fairly substantial improvement in most cases; so it's a good idea to enable it:<br />
<br />
# tune2fs -O dir_index /dev/hdXY<br />
<br />
This will only take effect with directories created on that filesystem after tune2fs is run. In order to apply this to currently existing directories, we must run the e2fsck utility to optimize and reindex the directories on the filesystem:<br />
<br />
# e2fsck -D -f /dev/hdXY<br />
<br />
'''Note:''' This should work with both ext2 and ext3 filesystems. Depending on the size of your filesystem, this could take a long time. Perhaps you should go get some coffee...<br />
<br />
==Enable Full Journaling==<br />
<br />
By default, ext3 partitions mount with the 'ordered' data mode. In this mode, all data is written to the main filesystem and its metadata is committed to the journal, whose blocks are logically grouped into transactions to decrease disk I/O. This tends to be a good default for most people. However, I've found a method that increases both reliability and performance (in some situations): journaling everything, including the file data itself (known as 'journal' data mode). Normally, one would think that journaling all data would decrease performance, because the data is written to disk twice: once to the journal then later committed to the main filesystem, but this does not seem to be the case. I've enabled it on all nine of my partitions and have only seen a minor performance loss in deleting large files. In fact, doing this can actually improve performance on a filesystem where much reading and writing is to be done simultaneously. See [http://www-106.ibm.com/developerworks/linux/library/l-fs8.html#4 this article] written by Daniel Robbins on IBM's website for more information.<br />
<br />
<br />
There are two different ways to activate journal data mode. The first is by adding data=journal as a mount option in /etc/fstab. If you do it this way and want your root filesystem to also use it, you should also pass rootflags=data=journal as a kernel parameter in your bootloader's configuration. In the second method, you will use tune2fs to modify the default mount options in the filesystem's superblock:<br />
<br />
# tune2fs -O has_journal -o journal_data /dev/hdXY<br />
Please note that the second method may not work for older kernels. Especially Linux 2.4.20 and below will likely disregard the default mount options on the superblock. If you're feeling adventurous you may also want to tweak the journal size. (I've left the journal size at the default.) A larger journal may give you better performance (at the cost of more disk space and longer recovery times). Please be sure to read the relevant section of the tune2fs manual before doing so:<br />
<br />
# tune2fs -J size=$SIZE /dev/hdXY<br />
<br />
==Disable Lengthy Boot-Time Checks==<br />
<br />
'''WARNING:''' Only do this on a journalling filesystem such as ext3. This may or may not work on other journalling filesystems such as ReiserFS or XFS, but has not been tested. Doing so may damage or otherwise corrupt other filesystems. You do this AT YOUR OWN RISK.<br />
<br />
Hmm..It seems that our ext3 filesystems are still being checked every 30 mounts or so. This is a good default for many because it helps prevent filesystem corruption when you have hardware issues, such as bad IDE/SATA/SCSI cabling, power supply failures, etc. One of the driving forces for creating journalling filesystems was that the filesystem could easily be returned to a consistent state by recovering and replaying the needed journalled transactions. Therefore, we can safely disable these mount-count- and time-dependent checks if we are certain the filesystem will be quickly checked to recover the journal if needed to restore filesystem and data consistency. Before you do this please make sure your filesystem entry in /etc/fstab has a positive integer in its 6th field (pass) so that it is checked at boot time automatically. You may do so using the following command:<br />
<br />
# tune2fs -c 0 -i 0 /dev/hdXY<br />
<br />
==User experiences==<br />
I get filesystem errors even with this tips. Do not disable lengthy Boot-Time</div>Pajarohttps://wiki.archlinux.org/index.php?title=Ext3&diff=22424Ext32007-03-30T10:19:09Z<p>Pajaro: </p>
<hr />
<div>[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Copyright==<br />
Copyright (c) 2005 Peter Gordon (codergeek42)<br />
<br />
Permission is granted to copy, distribute and/or modify this document<br />
under the terms of the GNU Free Documentation License, Version 1.2<br />
or any later version published by the Free Software Foundation;<br />
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover<br />
Texts. <br />
<br />
==Overview==<br />
<br />
I'm a big fan of the Third Extended ("ext3") filesystem. It's in-kernel and userspace code has been tried, tested, fixed, and improved upon more than almost every other Linux-compatible filesystem. It's simple, robust, and extensible. In this article I intend to explain some tips that can improve both the performance and the reliability of the filesystem.<br />
<br />
In the document, /dev/hdXY will be used as a generic partition. You should replace this with the actual device node for your partition, such as /dev/hdb1 for the first partition of the primary slave disk or /dev/sda2 for the second partition of your first SCSI or Serial ATA disk.<br />
<br />
==Using The tune2fs and e2fsck Utilities==<br />
<br />
Before we begin, we need to make sure you are comfortable with using the tune2fs utility to alter the filesystem options of an ext2 or ext3 partition. Please make sure to read the tune2fs man page:<br />
<br />
$ man tune2fs<br />
It's generally a good idea to run a filesystem check using the e2fsck utility after you've completed the alterations you wish to make on your filesystem. This will verify that your filesystem is clean and fix it if needed. You should also read the manual page for the e2fsck utility if you have not yet done so:<br />
<br />
$ man e2fsck<br />
<br />
'''WARNING:''' Make sure any filesystems are cleanly unmounted before altering them with the tune2fs or e2fsck utilities! (Boot from a LiveCD such as '''Archie''' or Knoppix if you need to.) Altering or tuning a filesystem while it is mounted can cause severe corruption! You have been warned!<br />
<br />
==Using Directory Indexing==<br />
<br />
This feature improves file access in large directories or directories containing many files by using hashed binary trees to store the directory information. It's perfectly safe to use, and it provides a fairly substantial improvement in most cases; so it's a good idea to enable it:<br />
<br />
# tune2fs -O dir_index /dev/hdXY<br />
<br />
This will only take effect with directories created on that filesystem after tune2fs is run. In order to apply this to currently existing directories, we must run the e2fsck utility to optimize and reindex the directories on the filesystem:<br />
<br />
# e2fsck -D -f /dev/hdXY<br />
<br />
'''Note:''' This should work with both ext2 and ext3 filesystems. Depending on the size of your filesystem, this could take a long time. Perhaps you should go get some coffee...<br />
<br />
==Enable Full Journaling==<br />
<br />
By default, ext3 partitions mount with the 'ordered' data mode. In this mode, all data is written to the main filesystem and its metadata is committed to the journal, whose blocks are logically grouped into transactions to decrease disk I/O. This tends to be a good default for most people. However, I've found a method that increases both reliability and performance (in some situations): journaling everything, including the file data itself (known as 'journal' data mode). Normally, one would think that journaling all data would decrease performance, because the data is written to disk twice: once to the journal then later committed to the main filesystem, but this does not seem to be the case. I've enabled it on all nine of my partitions and have only seen a minor performance loss in deleting large files. In fact, doing this can actually improve performance on a filesystem where much reading and writing is to be done simultaneously. See [http://www-106.ibm.com/developerworks/linux/library/l-fs8.html#4 this article] written by Daniel Robbins on IBM's website for more information.<br />
<br />
<br />
There are two different ways to activate journal data mode. The first is by adding data=journal as a mount option in /etc/fstab. If you do it this way and want your root filesystem to also use it, you should also pass rootflags=data=journal as a kernel parameter in your bootloader's configuration. In the second method, you will use tune2fs to modify the default mount options in the filesystem's superblock:<br />
<br />
# tune2fs -O has_journal -o journal_data /dev/hdXY<br />
Please note that the second method may not work for older kernels. Especially Linux 2.4.20 and below will likely disregard the default mount options on the superblock. If you're feeling adventurous you may also want to tweak the journal size. (I've left the journal size at the default.) A larger journal may give you better performance (at the cost of more disk space and longer recovery times). Please be sure to read the relevant section of the tune2fs manual before doing so:<br />
<br />
# tune2fs -J size=$SIZE /dev/hdXY<br />
<br />
==Disable Lengthy Boot-Time Checks==<br />
<br />
'''WARNING:''' Only do this on a journalling filesystem such as ext3. This may or may not work on other journalling filesystems such as ReiserFS or XFS, but has not been tested. Doing so may damage or otherwise corrupt other filesystems. You do this AT YOUR OWN RISK.<br />
<br />
Hmm..It seems that our ext3 filesystems are still being checked every 30 mounts or so. This is a good default for many because it helps prevent filesystem corruption when you have hardware issues, such as bad IDE/SATA/SCSI cabling, power supply failures, etc. One of the driving forces for creating journalling filesystems was that the filesystem could easily be returned to a consistent state by recovering and replaying the needed journalled transactions. Therefore, we can safely disable these mount-count- and time-dependent checks if we are certain the filesystem will be quickly checked to recover the journal if needed to restore filesystem and data consistency. Before you do this please make sure your filesystem entry in /etc/fstab has a positive integer in its 6th field (pass) so that it is checked at boot time automatically. You may do so using the following command:<br />
<br />
# tune2fs -c 0 -i 0 /dev/hdXY<br />
<br />
==User experiences==<br />
I get filesystem errors even with this tips. Do not disable lengthy Boot-Time</div>Pajarohttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=22168Professional audio2007-03-25T10:50:29Z<p>Pajaro: </p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
<br />
== Introduction to Professional Audio (ProAudio) in Linux ==<br />
<br />
Nowadays the quality of Linux got to the point in which professional audio is mature enough to consider using it as a professional audio sollution. The main reasons for this are:<br />
<br />
* In Linux you can easily get latencies in the range of 2-6 milliseconds.<br />
* There is a sound server (jack) that handles the communication between applications and sound cards in realtime.<br />
* There is a plugin system (ladspa) that provides you with professional reverbs and effects.<br />
* There are some professional apps that take profit of all this advantatges (ardour, rosegarden, etc).<br />
<br />
Now that you know that Linux can be good for you, you may want to check [[ProAudioCommercialToLinuxSoftware|Linux equivalents to popular commercial software]].<br />
<br />
== Starting up ==<br />
<br />
To start working with ProAudio you have to:<br />
#Add the proaduio repo to your pacman.conf:<br />
#:[proadio]<br />
#:Server = http://arch.madfire.net/proaudio/i686<br />
#run<br />
#:pacman -Syu<br />
#install ardour, rosegarden, qjackctl, caps, fst:<br />
#:pacman -S ardour rosegarden qjackctl caps fst<br />
#start qjackctl<br />
#open ardour or rosegarden<br />
#start learning the apps<br />
<br />
It is also recommended that you use a patched kernel. Keep reading.<br />
<br />
<br />
== ProAudio tips-n-tricks ==<br />
<br />
This page is aimed to give users quick tips on how to efficiently use or learn to use various audio mastering, recording and producing tools available on Linux.<br />
<br />
This thread http://bbs.archlinux.org/viewtopic.php?id=30547 is devoted to proaudio repository for Arch, which is the official supporter of this page.<br />
<br />
Please feel free to add quick tips and pointers to various FAQs and manuals for proaudio work on Linux.<br />
<br />
== Realtime Kernel Patches ==<br />
<br />
This is an absolute must for any serious audio work involving realtime - controlling software synths via midi or doing some continuous looping mixing (like in freewheeling/sooperlooper).<br />
<br />
http://rt.wiki.kernel.org/index.php/Main_Page<br />
<br />
== Realtime Kernel ( kernel26-rt-preempt ) ==<br />
<br />
I am currently developing a suitable realtime kernel package for Archlinux....<br />
Anyone wishing to test it before i commit it to the ProAudio repos email me : justin AT smithies DOT me DOT uk<br />
<br />
== Examples ==<br />
<br />
The forum post by Pajaro summarizes what should be found on this page:<br />
<br />
It would be good to make a page with a wiki explaining things like:<br />
<br />
* How to use VSTs: installation of VSTs with wine -> Quick guide to FST (maybe you could add it to your repo)<br />
* How to enable MIDI: Using soundcard / using virtual synth/sampler.<br />
* Quick guide to record audio with Ardou (aurdour is complex, but to start to use it you only need to know a few things.)<br />
* etc...<br />
<br />
This are things that can be done easily, but the information is spread all around, so you need to spend many hours searching on the net.<br />
<br />
The idea if this wiki would be to have information to start working. No tutorials. No manuals. Just quick guides and links for extended documentation.</div>Pajarohttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=22133Professional audio2007-03-23T23:14:56Z<p>Pajaro: </p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
<br />
== Introduction to Professional Audio (ProAudio) in Linux ==<br />
<br />
Nowadays the quality of Linux got to the point in which professional audio is mature enough to consider using it as a professional audio sollution. The main reasons for this are:<br />
<br />
* In Linux you can easily get latencies in the range of 2-6 milliseconds.<br />
* There is a sound server (jack) that handles the communication between applications and sound cards in realtime.<br />
* There is a plugin system (ladspa) that provides you with professional reverbs and effects.<br />
* There are some professional apps that take profit of all this advantatges (ardour, rosegarden, etc).<br />
<br />
Now that you know that Linux can be good for you, you may want to check [[ProAudioCommercialToLinuxSoftware|Linux equivalents to popular commercial software]].<br />
<br />
== ProAudio tips-n-tricks ==<br />
<br />
This page is aimed to give users quick tips on how to efficiently use or learn to use various audio mastering, recording and producing tools available on Linux.<br />
<br />
This thread http://bbs.archlinux.org/viewtopic.php?id=30547 is devoted to proaudio repository for Arch, which is the official supporter of this page.<br />
<br />
Please feel free to add quick tips and pointers to various FAQs and manuals for proaudio work on Linux.<br />
<br />
== Realtime Kernel Patches ==<br />
<br />
This is an absolute must for any serious audio work involving realtime - controlling software synths via midi or doing some continuous looping mixing (like in freewheeling/sooperlooper).<br />
<br />
http://rt.wiki.kernel.org/index.php/Main_Page<br />
<br />
== Realtime Kernel ( kernel26-rt-preempt ) ==<br />
<br />
I am currently developing a suitable realtime kernel package for Archlinux....<br />
Anyone wishing to test it before i commit it to the ProAudio repos email me : justin AT smithies DOT me DOT uk<br />
<br />
== Examples ==<br />
<br />
The forum post by Pajaro summarizes what should be found on this page:<br />
<br />
It would be good to make a page with a wiki explaining things like:<br />
<br />
* How to use VSTs: installation of VSTs with wine -> Quick guide to FST (maybe you could add it to your repo)<br />
* How to enable MIDI: Using soundcard / using virtual synth/sampler.<br />
* Quick guide to record audio with Ardou (aurdour is complex, but to start to use it you only need to know a few things.)<br />
* etc...<br />
<br />
This are things that can be done easily, but the information is spread all around, so you need to spend many hours searching on the net.<br />
<br />
The idea if this wiki would be to have information to start working. No tutorials. No manuals. Just quick guides and links for extended documentation.</div>Pajarohttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=22132Professional audio2007-03-23T23:14:13Z<p>Pajaro: </p>
<hr />
<div>[[Category:Audio/Video (English), ProAudio]]<br />
<br />
== Introduction to Professional Audio (ProAudio) in Linux ==<br />
<br />
Nowadays the quality of Linux got to the point in which professional audio is mature enough to consider using it as a professional audio sollution. The main reasons for this are:<br />
<br />
* In Linux you can easily get latencies in the range of 2-6 milliseconds.<br />
* There is a sound server (jack) that handles the communication between applications and sound cards in realtime.<br />
* There is a plugin system (ladspa) that provides you with professional reverbs and effects.<br />
* There are some professional apps that take profit of all this advantatges (ardour, rosegarden, etc).<br />
<br />
Now that you know that Linux can be good for you, you may want to check [[ProAudioCommercialToLinuxSoftware|Linux equivalents to popular commercial software]].<br />
<br />
== ProAudio tips-n-tricks ==<br />
<br />
This page is aimed to give users quick tips on how to efficiently use or learn to use various audio mastering, recording and producing tools available on Linux.<br />
<br />
This thread http://bbs.archlinux.org/viewtopic.php?id=30547 is devoted to proaudio repository for Arch, which is the official supporter of this page.<br />
<br />
Please feel free to add quick tips and pointers to various FAQs and manuals for proaudio work on Linux.<br />
<br />
== Realtime Kernel Patches ==<br />
<br />
This is an absolute must for any serious audio work involving realtime - controlling software synths via midi or doing some continuous looping mixing (like in freewheeling/sooperlooper).<br />
<br />
http://rt.wiki.kernel.org/index.php/Main_Page<br />
<br />
== Realtime Kernel ( kernel26-rt-preempt ) ==<br />
<br />
I am currently developing a suitable realtime kernel package for Archlinux....<br />
Anyone wishing to test it before i commit it to the ProAudio repos email me : justin AT smithies DOT me DOT uk<br />
<br />
== Examples ==<br />
<br />
The forum post by Pajaro summarizes what should be found on this page:<br />
<br />
It would be good to make a page with a wiki explaining things like:<br />
<br />
* How to use VSTs: installation of VSTs with wine -> Quick guide to FST (maybe you could add it to your repo)<br />
* How to enable MIDI: Using soundcard / using virtual synth/sampler.<br />
* Quick guide to record audio with Ardou (aurdour is complex, but to start to use it you only need to know a few things.)<br />
* etc...<br />
<br />
This are things that can be done easily, but the information is spread all around, so you need to spend many hours searching on the net.<br />
<br />
The idea if this wiki would be to have information to start working. No tutorials. No manuals. Just quick guides and links for extended documentation.</div>Pajarohttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=22114Professional audio2007-03-23T08:17:43Z<p>Pajaro: </p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
<br />
== Introduction to Professional Audio (ProAudio) in Linux ==<br />
<br />
Nowadays the quality of Linux got to the point in which professional audio is mature enough to consider using it as a professional audio sollution. The main reasons for this are:<br />
<br />
* In Linux you can easily get latencies in the range of 2-6 milliseconds.<br />
* There is a sound server (jack) that handles the communication between applications and sound cards in realtime.<br />
* There is a plugin system (ladspa) that provides you with professional reverbs and effects.<br />
* There are some professional apps that take profit of all this advantatges (ardour, rosegarden, etc).<br />
<br />
Now that you know that Linux can be good for you, you may want to check [[ProAudioCommercialToLinuxSoftware|Linux equivalents to popular commercial software]].<br />
<br />
== ProAudio tips-n-tricks ==<br />
<br />
This page is aimed to give users quick tips on how to efficiently use or learn to use various audio mastering, recording and producing tools available on Linux.<br />
<br />
This thread http://bbs.archlinux.org/viewtopic.php?id=30547 is devoted to proaudio repository for Arch, which is the official supporter of this page.<br />
<br />
Please feel free to add quick tips and pointers to various FAQs and manuals for proaudio work on Linux.<br />
<br />
== Realtime Kernel Patches ==<br />
<br />
This is an absolute must for any serious audio work involving realtime - controlling software synths via midi or doing some continuous looping mixing (like in freewheeling/sooperlooper).<br />
<br />
http://rt.wiki.kernel.org/index.php/Main_Page<br />
<br />
== Examples ==<br />
<br />
The forum post by Pajaro summarizes what should be found on this page:<br />
<br />
It would be good to make a page with a wiki explaining things like:<br />
<br />
* How to use VSTs: installation of VSTs with wine -> Quick guide to FST (maybe you could add it to your repo)<br />
* How to enable MIDI: Using soundcard / using virtual synth/sampler.<br />
* Quick guide to record audio with Ardou (aurdour is complex, but to start to use it you only need to know a few things.)<br />
* etc...<br />
<br />
This are things that can be done easily, but the information is spread all around, so you need to spend many hours searching on the net.<br />
<br />
The idea if this wiki would be to have information to start working. No tutorials. No manuals. Just quick guides and links for extended documentation.</div>Pajarohttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=22113Professional audio2007-03-23T08:16:31Z<p>Pajaro: </p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
<br />
== Introduction to Professional Audio (ProAudio) in Linux ==<br />
<br />
Nowadays the quality of Linux got to the point in which professional audio is mature enough to consider using it as a professional audio sollution. The main reasons for this are:<br />
<br />
* In Linux you can easily get latencies in the range of 2-6 milliseconds.<br />
* There is a sound server (jack) that handles the communication between applications and sound cards in realtime.<br />
* There is a plugin system (ladspa) that provides you with professional reverbs and effects.<br />
* There are some professional apps that take profit of all this advantatges (ardour, rosegarden, etc).<br />
<br />
Now that you know that Linux can be good for you, you may what to check [[ProAudioCommercialToLinuxSoftware|Linux equivalents to commercial software]].<br />
<br />
== ProAudio tips-n-tricks ==<br />
<br />
This page is aimed to give users quick tips on how to efficiently use or learn to use various audio mastering, recording and producing tools available on Linux.<br />
<br />
This thread http://bbs.archlinux.org/viewtopic.php?id=30547 is devoted to proaudio repository for Arch, which is the official supporter of this page.<br />
<br />
Please feel free to add quick tips and pointers to various FAQs and manuals for proaudio work on Linux.<br />
<br />
== Realtime Kernel Patches ==<br />
<br />
This is an absolute must for any serious audio work involving realtime - controlling software synths via midi or doing some continuous looping mixing (like in freewheeling/sooperlooper).<br />
<br />
http://rt.wiki.kernel.org/index.php/Main_Page<br />
<br />
== Examples ==<br />
<br />
The forum post by Pajaro summarizes what should be found on this page:<br />
<br />
It would be good to make a page with a wiki explaining things like:<br />
<br />
* How to use VSTs: installation of VSTs with wine -> Quick guide to FST (maybe you could add it to your repo)<br />
* How to enable MIDI: Using soundcard / using virtual synth/sampler.<br />
* Quick guide to record audio with Ardou (aurdour is complex, but to start to use it you only need to know a few things.)<br />
* etc...<br />
<br />
This are things that can be done easily, but the information is spread all around, so you need to spend many hours searching on the net.<br />
<br />
The idea if this wiki would be to have information to start working. No tutorials. No manuals. Just quick guides and links for extended documentation.</div>Pajarohttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=22112Professional audio2007-03-23T08:08:49Z<p>Pajaro: </p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
<br />
== Introduction to Professional Audio (ProAudio) in Linux ==<br />
<br />
Nowadays the quality of Linux got to the point in which professional audio is mature enough to consider using it as a professional audio sollution. The main reasons for this are:<br />
<br />
* In Linux you can easily get latencies in the range of 2-6 milliseconds.<br />
* There is a sound server (jack) that handles the communication between applications and sound cards in realtime.<br />
* There is a plugin system (ladspa) that provides you with professional reverbs and effects.<br />
* There are some professional apps that take profit of all this advantatges (ardour, rosegarden, etc).<br />
<br />
== ProAudio tips-n-tricks ==<br />
<br />
This page is aimed to give users quick tips on how to efficiently use or learn to use various audio mastering, recording and producing tools available on Linux.<br />
<br />
This thread http://bbs.archlinux.org/viewtopic.php?id=30547 is devoted to proaudio repository for Arch, which is the official supporter of this page.<br />
<br />
Please feel free to add quick tips and pointers to various FAQs and manuals for proaudio work on Linux.<br />
<br />
== Realtime Kernel Patches ==<br />
<br />
This is an absolute must for any serious audio work involving realtime - controlling software synths via midi or doing some continuous looping mixing (like in freewheeling/sooperlooper).<br />
<br />
http://rt.wiki.kernel.org/index.php/Main_Page<br />
<br />
== Examples ==<br />
<br />
The forum post by Pajaro summarizes what should be found on this page:<br />
<br />
It would be good to make a page with a wiki explaining things like:<br />
<br />
* How to use VSTs: installation of VSTs with wine -> Quick guide to FST (maybe you could add it to your repo)<br />
* How to enable MIDI: Using soundcard / using virtual synth/sampler.<br />
* Quick guide to record audio with Ardou (aurdour is complex, but to start to use it you only need to know a few things.)<br />
* etc...<br />
<br />
This are things that can be done easily, but the information is spread all around, so you need to spend many hours searching on the net.<br />
<br />
The idea if this wiki would be to have information to start working. No tutorials. No manuals. Just quick guides and links for extended documentation.</div>Pajarohttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=22072Professional audio2007-03-20T12:24:08Z<p>Pajaro: </p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
<br />
== Introduction to Professional Audio (ProAudio) in Linux ==<br />
<br />
Nowadays the quality of Linux got to the point in which professional audio is mature enough to consider using it as a professional audio sollution. The main reasons for this are:<br />
<br />
* In Linux you can easily get latencies in the range of 2-6 milliseconds.<br />
* There is a sound server (jack) that handles the communication between applications and sound cards in realtime.<br />
* There is a plugin system (ladspa) that provides you with professional reverbs and effects.<br />
* There are some professional apps that take profit of all this advantatges (ardour, rosegarden, etc).<br />
<br />
== ProAudio tips-n-tricks ==<br />
<br />
This page is aimed to give users quick tips on how to efficiently use or learn to use various audio mastering, recording and producing tools available on Linux.<br />
<br />
This thread http://bbs.archlinux.org/viewtopic.php?id=30547 is devoted to proaudio repository for Arch, which is the official supporter of this page.<br />
<br />
Please feel free to add quick tips and pointers to various FAQs and manuals for proaudio work on Linux.<br />
<br />
== Realtime Kernel Patches ==<br />
<br />
This is an absolute must for any serious audio work involving realtime - controlling software synths via midi or doing some continuous looping mixing (like in freewheeling/sooperlooper).<br />
<br />
http://rt.wiki.kernel.org/index.php/Main_Page<br />
<br />
== Examples ==<br />
<br />
The forum post by Pajaro summarizes what should be found on this page:<br />
<br />
It would be good to make a page with a wiki explaining things like:<br />
<br />
- How to use VSTs: installation of VSTs with wine -> Quick guide to FST (maybe you could add it to your repo)<br />
- How to enable MIDI: Using soundcard / using virtual synth/sampler.<br />
- Quick guide to record audio with Ardou (aurdour is complex, but to start to use it you only need to know a few things.)<br />
- etc...<br />
<br />
This are things that can be done easily, but the information is spread all around, so you need to spend many hours searching on the net.<br />
<br />
The idea if this wiki would be to have information to start working. No tutorials. No manuals. Just quick guides and links for extended documentation.</div>Pajarohttps://wiki.archlinux.org/index.php?title=CurlFtpFS&diff=16567CurlFtpFS2006-11-04T10:25:44Z<p>Pajaro: </p>
<hr />
<div>[[Category:Network]]<br />
[[Category:Filesystem]]<br />
<br />
The packages are all located in AUR. It is recomended that you use a tool like [[qpkg]] or [[aurbuild]] to install them.<br />
<br />
== Packages ==<br />
This are the packages that provide a way to mount FTP shares:<br />
<br />
* curlftpfs [recomended]<br />
* fuseftp<br />
* lufs [outdated]<br />
<br />
They are based on [[fuse]].</div>Pajarohttps://wiki.archlinux.org/index.php?title=CurlFtpFS&diff=16566CurlFtpFS2006-11-04T10:23:24Z<p>Pajaro: </p>
<hr />
<div>[[Category:Network]]<br />
[[Category:Filesystem]]<br />
<br />
The packages are all located in AUR. It is recomended that you use a tool like [[qpkg]] or [[aurbuild]] to install them.<br />
<br />
== Packages ==<br />
This are the packages that provide a way to mount FTP shares:<br />
<br />
* fuseftp<br />
* curlftpfs<br />
* lufs<br />
<br />
They are based on [[fuse]].</div>Pajarohttps://wiki.archlinux.org/index.php?title=CurlFtpFS&diff=16565CurlFtpFS2006-11-04T10:23:05Z<p>Pajaro: </p>
<hr />
<div>[[Category:Network|Filesystem]]<br />
<br />
The packages are all located in AUR. It is recomended that you use a tool like [[qpkg]] or [[aurbuild]] to install them.<br />
<br />
== Packages ==<br />
This are the packages that provide a way to mount FTP shares:<br />
<br />
* fuseftp<br />
* curlftpfs<br />
* lufs<br />
<br />
They are based on [[fuse]].</div>Pajarohttps://wiki.archlinux.org/index.php?title=CurlFtpFS&diff=16564CurlFtpFS2006-11-04T10:22:57Z<p>Pajaro: </p>
<hr />
<div>[[Category:Network Filesystem]]<br />
<br />
The packages are all located in AUR. It is recomended that you use a tool like [[qpkg]] or [[aurbuild]] to install them.<br />
<br />
== Packages ==<br />
This are the packages that provide a way to mount FTP shares:<br />
<br />
* fuseftp<br />
* curlftpfs<br />
* lufs<br />
<br />
They are based on [[fuse]].</div>Pajarohttps://wiki.archlinux.org/index.php?title=CurlFtpFS&diff=16563CurlFtpFS2006-11-04T10:21:38Z<p>Pajaro: </p>
<hr />
<div>[[Category:Network]]<br />
<br />
The packages are all located in AUR. It is recomended that you use a tool like [[qpkg]] or [[aurbuild]] to install them.<br />
<br />
== Packages ==<br />
This are the packages that provide a way to mount FTP shares:<br />
<br />
* fuseftp<br />
* curlftpfs<br />
* lufs<br />
<br />
They are based on [[fuse]].</div>Pajarohttps://wiki.archlinux.org/index.php?title=Beryl&diff=15995Beryl2006-10-26T07:41:13Z<p>Pajaro: </p>
<hr />
<div>Beryl is a window and composition manager. It has been created as a fork of compiz. Beryl is currently only available via svn, although a first release is expected soon.<br />
<br />
= Installing Beryl =<br />
==From binary packages==<br />
There are binary packages available in the unstable repository. Make sure the unstable repository is enabled in your pacman configuration.<br />
Install beryl using the command<br />
# pacman -Sy beryl-svn<br />
This will install all necessary packages.<br />
<br />
==From source==<br />
Beryl is only available through SVN right now. PKGBUILDs for the components can be found in Archlinux CVS:<br />
* [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11/beryl-core-svn/?cvsroot=Unstable&only_with_tag=CURRENT beryl-core-svn] (Beryl main program)<br />
* [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11/beryl-plugins-svn/?cvsroot=Unstable&only_with_tag=CURRENT beryl-plugins-svn] (Beryl effect plugins)<br />
* [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11/beryl-manager-svn/?cvsroot=Unstable&only_with_tag=CURRENT beryl-manager-svn] (Beryl management dockapp)<br />
* [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11/beryl-dbus-svn/?cvsroot=Unstable&only_with_tag=CURRENT beryl-dbus-svn] (Beryl dbus plugin. Note that all other dbus dependencies have been removed from beryl, so a dbus session is no longer necessary to run beryl)<br />
* [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11/beryl-settings-svn/?cvsroot=Unstable&only_with_tag=CURRENT beryl-settings-svn] (Beryl settings manager)<br />
* [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11/emerald-svn/?cvsroot=Unstable&only_with_tag=CURRENT emerald-svn] (Beryl window decorator)<br />
* [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11/emerald-themes-svn/?cvsroot=Unstable&only_with_tag=CURRENT emerald-themes-svn] (Themes for window decoration)<br />
<br />
To build these packages, use versionpkg (pacman -S versionpkg with [community] repository enabled in /etc/pacman.conf), it will check out the latest svn release automatically.<br />
<br />
= Preparing Xorg for hardware accelerated effects =<br />
<br />
== Using nvidia drivers ==<br />
<br />
You have the choice of using the beta drivers and removing Xgl from your system, or use the official driver release and use Xgl.<br />
<br />
=== Official driver release ===<br />
<br />
If you want to use the official driver, see [[How to install NVIDIA driver]] if you still don't use it. You will also need Xgl. Refer to the other section about it on this page.<br />
<br />
=== Beta drivers ===<br />
<br />
The new nvidia beta driver support the long awaited "GLX_Texture_From_Pixmap" extension. That means you DON'T NEED Xgl anymore!<br />
<br />
You need the latest nvidia beta drivers. You can install them with pacman if the [unstable] repository is enabled in pacman.conf:<br />
<br />
stock kernel:<br />
# pacman -S nvidia-beta<br />
<br />
beyond kernel:<br />
# pacman -S nvidia-beta-beyond<br />
<br />
to search for others:<br />
# pacman -Ss nvidia-beta<br />
<br />
The PKGBUILDs can be found in the Archlinux unstable CVS tree.<br />
<br />
Then edit the ''/etc/X11/xorg.conf'' file:<br />
<br />
Section "Module"<br />
[...]<br />
Load "glx"<br />
[...]<br />
EndSection<br />
<br />
[...]<br />
<br />
Section "Device"<br />
Driver "nvidia"<br />
[...]<br />
Option "AddARGBGLXVisuals"<br />
EndSection<br />
<br />
[...]<br />
<br />
Section "Extensions"<br />
Option "Composite" "Enable"<br />
EndSection<br />
<br />
== Using open source drivers and AIGLX ==<br />
<br />
AIGLX currently works with the open source Intel and Radeon drivers. Add the following to your ''/etc/X11/xorg.conf'' file to enable AIGLX:<br />
Section "Module"<br />
[...]<br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
[...]<br />
<br />
Section "Device"<br />
[...]<br />
Option "XAANoOffscreenPixmaps" "true"<br />
Option "DRI" "true"<br />
EndSection<br />
<br />
[...]<br />
<br />
Section "ServerLayout"<br />
[...]<br />
Option "AIGLX" "true"<br />
EndSection<br />
<br />
[...]<br />
<br />
Section "Extensions"<br />
Option "Composite" "true"<br />
EndSection<br />
If your xorg driver doesn't support AIGLX, then the effects won't work.<br />
<br />
== Using XGL ==<br />
<br />
Refer to this [http://wiki.archlinux.org/index.php/Xgl#Install_Xgl wiki entry] for installing Xgl.<br />
<br />
= Starting Beryl =<br />
<br />
== XFCE Desktop ==<br />
<br />
The ''startxfce4'' script and the ''xfce4-session'' tool don't seem to work with beryl yet, as it seems to lack proper X Session Management support. To use xfce with beryl, you have to modify your ''$HOME/.xsession'' and/or ''$HOME/.xinitrc'' script. ''xinitrc'' is used by startx, ''xsession'' is used by gdm and kdm if you select the ''Custom'' session.<br />
<br />
NOTE: The default ''.xsession'' script only launches the ''.xinitrc'' script, so most people will have to edit ''.xinitrc''.<br />
<br />
Your script has to start dbus and all beryl and xfce components. Here is an example:<br />
<br />
. /etc/profile<br />
. $HOME/.bashrc<br />
<br />
is_running() {<br />
for pid in $(pidof "$1"); do<br />
if kill -0 $pid 2>/dev/null; then<br />
return 0<br />
fi<br />
done<br />
return 1<br />
}<br />
xrdb $HOME/.Xresources<br />
<br />
# start a dbus session bus, if it is not already running<br />
# This is no longer necessary with newer beryl versions<br />
if ! is_running dbus-daemon; then<br />
dbus-launch --sh-syntax > $HOME/.dbus-env<br />
fi<br />
source $HOME/.dbus-env<br />
<br />
# start beryl and beryl-manager<br />
beryl-start<br />
beryl-manager &<br />
# start necessary xfce components<br />
xfce-mcs-manager<br />
xftaskbar4 & # REMOVE THIS LINE IF YOU USE XFCE-SVN<br />
xfcalendar & # REMOVE THIS LINE IF YOU USE XFCE-SVN<br />
xfdesktop & <br />
xfce4-panel & wmpid=$!<br />
<br />
# start any other needed programs here<br />
<br />
wait $wmpid<br />
<br />
<br />
=== Alternative ===<br />
<br />
You can run xfce4 with startxfce4 or xfce-session and gdm (probably kdm too) by modifying some files.<br />
<br />
First edit /etc/X11/XFCE4-svn.desktop (this is the file for svn version. For xfce 4.2 it should probably be XFCE4.desktop):<br />
<br />
[Desktop Entry]<br />
Encoding=UTF-8<br />
Type=XSession<br />
Exec=~/.xsession<br />
TryExec=/opt/xfce4/bin/startxfce4<br />
Name=XFCE4-svn<br />
<br />
Next edit ~/.xinitrc:<br />
<br />
#!/bin/sh<br />
<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
#<br />
<br />
. /etc/profile<br />
. $HOME/.bashrc<br />
<br />
is_running() {<br />
for pid in $(pidof "$1"); do<br />
if kill -0 $pid 2>/dev/null; then<br />
return 0<br />
fi<br />
done<br />
return 1<br />
}<br />
xrdb $HOME/.Xresources<br />
<br />
# start a dbus session bus, if it is not already running<br />
if ! is_running dbus-daemon; then<br />
dbus-launch --sh-syntax > $HOME/.dbus-env<br />
fi<br />
source $HOME/.dbus-env<br />
<br />
# start beryl and beryl-manager<br />
beryl-manager &<br />
emerald & <br />
startxfce4 <br />
<br />
And finally delete your previous sessions stored by xfce4:<br />
<br />
rm -r .cache/sessions/*<br />
<br />
NOTE:If you were modifying these files while running xfce4 do not save your session on exit.<br />
<br />
== KDE Desktop ==<br />
<br />
Create ''~/.kde/Autostart/startup'' with the following contents:<br />
#!/bin/sh<br />
beryl-start<br />
beryl-manager &<br />
<br />
Finally make this script executable (e.g. ''chmod 755 ~/.kde/Autostart/startup'') and you are ready.<br />
<br />
== GNOME Desktop ==<br />
<br />
The simplest way is to add beryl-start to the applications that start with your session. You can do this by going to:<br />
[Desktop] -> [Preferences] -> [Sessions] -> [Startup Programs]<br />
Adding beryl-manager to the list might be a good idea too so you can switch back to Metacity if need be.<br />
<br />
== No Desktop, Beryl as window manager only ==<br />
<br />
This is an example ''~/.xinitrc'' to create a "lightweight" Beryl environment. It is rather unconfortable unless you add a panel and maybe other management applications.<br />
<br />
if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then<br />
eval `dbus-launch --sh-syntax --exit-with-session`<br />
fi<br />
<br />
emerald &<br />
beryl-manager &<br />
<br />
# Start other applications here<br />
# <br />
# Example: set wallpaper + open a terminal<br />
#<br />
# feh --bg-scale ~/Wallpapers/wallpaper.jpg &<br />
# urxvt -depth 32 -fg grey80 -bg rgba:0000/0000/0000/dddd &<br />
<br />
# Remove '--indirect-rendering --strict-binding' from the following line if you are not using AIGLX<br />
exec /usr/bin/beryl --indirect-rendering --strict-binding dbus settings<br />
<br />
= Configuring Beryl =<br />
<br />
beryl (WM and compositor): Just run "beryl-settings"<br />
<br />
emerald (window decorator): run "emerald-theme-manager"<br />
<br />
Running "beryl-manager" will give you more control on beryl. With that nice tray icon you can get back to metacity/kwin, launch the beryl settings or the theme manager, etc.<br />
<br />
You can migrate compiz-quinn's settings to beryl by copying ~/.compiz/csm_settings to ~/.beryl/settings<br />
<br />
= Troubleshooting =<br />
<br />
== nvidia beta drivers and black windows ==<br />
This is saddly the only thing preventing me form using beryl... When windows are maximinsed of big enough, they get black. Getting them smaller may get their content back. It seems that its a bug in the nvidia beta drivers.<br />
<br />
See the [http://bugs.beryl-project.org/ticket/201 Beryl's bug tracker #201]:<br />
This is an nVidia problem, from nVidia (James Jones) on nvnews<br />
http://www.nvnews.net/vbulletin/showthread.php?t=77248&highlight=black+windows:<br />
<br />
"This is a shortcoming of the current implementation of<br />
GLX_EXT_texture_from_pixmap in the drivers. When video<br />
RAM has been exhausted, the driver does not behave well<br />
(you get blank windows). TurboCache? memory is currently<br />
cannot be used with GLX_EXT_texture_from_pixmap, so these<br />
problems will be especially noticeable on these parts.<br />
We're working on improving these cases."<br />
<br />
== ATI ==<br />
You should read this if you have prolems with ATI.<br />
<br />
=== Uninstalling fglrx ===<br />
<br />
Don't forget that:<br />
<br />
* xf86-video-ati are the ATI open source drivers<br />
* ati-fglrx(-beyond, ...) are the proprietary ones wich won't work with Beryl<br />
* You have to replace "fglrx" by "radeon" in BOTH the xorg.conf and rc.conf files<br />
* You have to uninstall ati-fglrx(-beyond, ...), ati-fglrx-utils and then install libgl-dri to get everything to work properly. As Veek said on [http://bbs.archlinux.org/viewtopic.php?t=22300&postdays=0&postorder=asc&highlight=libgldri&start=20 this post] :<br />
Attention, anyone who was previously using the fglrx drivers:<br />
Both the ati-fglrx-utils package and the libgl-dri package provide a version of the openGL<br />
shared library /usr/lib/libGL.so.1 (your version may be different).<br />
However the one supplied by the Mesa package implements things not implemented by the one in ATI's package.<br />
That's why it can be exceedingly confusing trying to figure out why things aren't working<br />
even though you apparently have the necessary libraries.<br />
The solution is to install libgl-dri and everything shoud work as outlined in spack's guide.<br />
<br />
This is my understanding of the issue, just wanted to clarify for anyone else that was confused.<br />
<br />
* Uninstalling commands:<br />
pacman -Rd ati-fglrx(-beyond,...) ati-fglrx-utils<br />
pacman -S libgl-dri<br />
<br />
=== Issues ===<br />
<br />
* I had some black screen troubles when trying to launch KDE. Sometimes KDE would also crash. It is fixed when adding the next line to the Device section of the rc.conf :<br />
<br />
BusID "PCI:1:0:0"<br />
<br />
* After this KDE would launch but a bit slowly and glxgears wouldn't launch but complaining :<br />
<br />
*********************************WARN_ONCE******** *************************<br />
File radeon_mm.c function radeon_mm_alloc line 216<br />
Ran out of GART memory!<br />
Please consider adjusting GARTSize option.<br />
************************************************** *************************<br />
<br />
Fixed when you add the following line to the device section of your xorg.conf (seen on [http://www.ubuntuforums.org/showthread.php?t=206642 this post]) :<br />
Option "GARTSize" "64"<br />
<br />
So everything works fine here on my ATI Radeon Mobility 9600, Beryl and KDE.<br />
Here is [http://alaux.net/files/public/xorg.conf.txt my xorg.conf]<br />
<br />
=== Desktop clipping/drawing error on Radeon 7500 ===<br />
Users of Radeon 7500 graphics cards may experience a "clipping" effect where the deskop is limited to 1024x768 resolution. Screen areas outside this box are not drawn correctly, and larger windows lack decorations etc.<br />
<br />
The fix for this is to download & build driconf from aur. Then set up your graphics card as you wish. The program creates a file called .driconf in yout home directory.<br />
<br />
Open this file, and change the line<br />
<br />
<option name="allow_large_textures" value="X" /> <br />
where "X" equals the current value there, and change it to<br />
<option name="allow_large_textures" value="2" /><br />
<br />
== window decorations disappear after beryl starts ==<br />
If you are using KDE, open: KDE Control Center -> Desktop -> Behavior<br />
and check "Show Icons on desktop" option.</div>Pajarohttps://wiki.archlinux.org/index.php?title=CurlFtpFS&diff=15908CurlFtpFS2006-10-20T08:44:59Z<p>Pajaro: </p>
<hr />
<div>[[Category:Network]]<br />
<br />
The packages are all located in AUR. It is recomended that you use a tool like qpkg to install them.<br />
<br />
== Packages ==<br />
This are the packages that provide a way to mount FTP shares.<br />
<br />
* fuseftp<br />
* curlftpfs<br />
* lufs</div>Pajarohttps://wiki.archlinux.org/index.php?title=CurlFtpFS&diff=15907CurlFtpFS2006-10-20T08:43:37Z<p>Pajaro: </p>
<hr />
<div>[[Category:Network]]<br />
<br />
== Packages ==<br />
This are the packages that provide a way to mount FTP shares.<br />
<br />
* fuseftp<br />
* curlftpfs<br />
* lufs</div>Pajaro