https://wiki.archlinux.org/api.php?action=feedcontributions&user=Samwise&feedformat=atomArchWiki - User contributions [en]2024-03-28T13:56:47ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Suspending_to_RAM_with_hibernate-script&diff=69468Suspending to RAM with hibernate-script2009-05-26T03:56:07Z<p>Samwise: Made some small clarifications.</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
====Overview====<br />
In this article we will explain how to accomplish a successful suspension to ram: all the processes are stopped and the current state of your machine is saved to ram. All the devices enter a low-consumption state and it will be very fast to resume the machine.<br />
Suspension to RAM is an acpi state, but the operation is almost never as simple as telling the machine to enter that state. The vast majority of laptops require additional operations and tricks. However, since this is quite an important feature for laptop users, it is worth spending some hours in finding the working combinations of tricks for your machine.<br />
<br />
====Different Methods of Suspending to RAM====<br />
There is an application, called s2ram, which contains a "whitelist" of known laptop models and, according to what has been reported by other owners of these laptops, tries to do the right things for that specific laptop. The whitelisted laptops can therefore use s2ram to suspend to ram "out of the box". Non-whitelisted laptops need to try different command line options of s2ram in order to determine - by trial and error - the appropriate "tricks" needed to make suspend and resume work. Your experience, if reported to the s2ram developers, will contribute to whitelist your machine in the next release of s2ram.<br />
<br />
However, s2ram is not the only resource: the hibernate-script, which is commonly used to accomplish [[Suspend to Disk]] , supports also suspension to RAM and proposes some further tricks which could convince your machine to suspend to ram and resume properly. Moreover, the hibernate-script can automatize other useful operations which you could want/need to do before suspension or after resuming from suspension to ram.<br />
<br />
Thus, the first part of this article will be devoted to s2ram. The second will discuss the use of the hibernate-script in suspension to ram. In particular, we will see how the hibernate-script can be used to suspend to ram your system just with the s2ram, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to ram and to disk.<br />
<br />
===s2ram===<br />
<br />
The s2ram utility is part of the uswsusp collection, which includes also some goodies relative to [[Suspend to Disk]] . You can find uswsusp in the community repositories.<br />
<br />
Read the notes provided by pacman during the ''uswsusp'' package installation. In essence, you will need to:<br />
* edit /etc/suspend.conf to specify the resume device<br />
resume device = /dev/sd''XY''<br />
* update /etc/mkinitcpio.conf to include the ''uresume'' hook<br />
HOOKS="base udev autodetect pata scsi sata ''uresume'' filesystems"<br />
* rebuild the ramdisk<br />
mkinitcpio -p kernel26<br />
<br />
=====Testing=====<br />
After installing the uswsusp package, check to see whether s2ram recognizes your machine:<br />
<br />
# s2ram -n<br />
<br />
If you see a line that says "Machine matched entry #", then your machine is already whitelisted. You SHOULD be able to suspend and resume properly by simply running s2ram:<br />
<br />
# s2ram<br />
<br />
Please note that the way to trigger resume from a suspended to RAM machine depends from your BIOS settings and is not predictable in general (sometimes it is enough to press a key whatsoever). If s2ram seems to work, but something goes wrong in the suspension cycle, then some driver or some process is causing problems and you should look at the hibernate section to see how the hibernate-script can help you. In the worst case, your machine has been erroneously whitelisted due to an inadequate report from another owner of the same machine. You should then report your case to the suspend-devel@lists.sourceforge.net, so that the previous mistaken report can stand corrected. In this case, you should quote the identification strings provided by s2ram -i.<br />
<br />
If s2ram doesn't match your machine to an entry in its whitelist, it will output some general purpose identification strings for your machine (the same as those provided s2ram -i). In this case, you will have to force s2ram to suspend your machine by using s2ram -f.<br />
<br />
<br />
If '''s2ram -f''' doesn't work, try the different workarounds offered by s2ram. Run s2ram -h to get a list of the possible options:<br />
# s2ram -h<br />
Usage: s2ram [-nhi] [-fspmrav]<br />
<br />
Options:<br />
-h, --help: this text.<br />
-n, --test: test if the machine is in the database.<br />
returns 0 if known and supported<br />
-i, --identify: prints a string that identifies the machine.<br />
-f, --force: force suspending, even on unknown machines.<br />
<br />
The following options are only available with -f/--force:<br />
-s, --vbe_save: save VBE state before suspending and restore after resume.<br />
-p, --vbe_post: VBE POST the graphics card after resume<br />
-m, --vbe_mode: get VBE mode before suspend and set it after resume<br />
-r, --radeontool: turn off the backlight on radeons before suspending.<br />
-a, --acpi_sleep: set the acpi_sleep parameter before suspend<br />
1=s3_bios, 2=s3_mode, 3=both<br />
-v, --pci_save: save the PCI config space for the VGA card.<br />
<br />
Try the following variations:<br />
s2ram -f -a 1<br />
s2ram -f -a 2<br />
s2ram -f -a 3<br />
s2ram -f -p -m<br />
s2ram -f -p -s<br />
s2ram -f -m<br />
s2ram -f -s<br />
s2ram -f -p<br />
s2ram -f -a 1 -m<br />
s2ram -f -a 1 -s<br />
<br />
If none of those combinations work, start again but add the "-v" switch.<br />
<br />
Note that mixing the "-a" options and the vbetool options ("-p", "-m", "-s")<br />
is normally only a measure of last resort, it usually does not make much<br />
sense.<br />
<br />
<br />
If you find several combinations that work (e.g. "s2ram -f -a 3" and "s2ram -f -p -m" both work on your machine),<br />
the in-kernel method ("-a") should be preferred over the userspace methods ("-p", "-m" and "-s").<br />
<br />
Verify all combinations in both cases when reporting success to the s2ram developers:<br />
* when issuing s2ram from console<br />
* when issuing s2ram from X<br />
<br />
<br />
You should really try ANY combination of these options (the only exception is the radeontool one, which can be useuful only if you have a radeon card), until you find a working combination. When you find a working combination, try to reduce it (that is try to see if any of the options are redundant). With any working combination of options, it is crucial to verify that suspension and resuming work fine both if you suspend from X and if you suspend from the plain console. Actually, in many setups the most tricky thing is to suspend and resume properly from the console. In the best case, s2ram -f is enough: this means that your machine does not require any trick to properly suspend and resume.<br />
<br />
There is a trick which does not correspond to a command line option, because it requires additional operations from you. It is marked with NOFB in the whitelist and used for those laptops which suspend and resume properly only if no framebuffer is used. If you verify that no command line option of s2ram works, you can try to disable the framebuffer. In order to do this, you need to edit your grub configuration /boot/grub/menu.lst (or the corresponding lilo file), remove the vga=<foo> value from the kernel line and reboot. This at least if you use the VESAFB framebufeer (as in the arch default kernel). If you use a different framebuffer driver, refer to the documentation of the driver to see how to disable it. <br />
<br />
After you have identified the shortest working combination of options, you should do two things. First, you will want to modify the whitelist for your local copy of s2ram to allow your machine to suspend and resume without any special options. Second, you will want to let the developers of s2ram know what options are needed for your machine so it can be added to the whitelist for future releases s2ram.<br />
<br />
Finally, it may happen that no trick makes s2ram work. In this case - before giving up - you can use some last-resort tricks provided by the hibernation-script discussed later in this article.<br />
<br />
=====Whitelisting=====<br />
To add your machine to the local whitelist for s2ram, you need to customize the package from [[ABS]]. Copy the /var/abs/community/system/uswsusp folder somewhere then run makepkg -o to download the sources. After this, edit the file src/suspend-0.8/whitelist.c<br />
<br />
You will see something like this: <br />
<br />
struct machine_entry whitelist[] = {<br />
{ "IBM", "", "ThinkPad X32", "", RADEON_OFF|S3_BIOS|S3_MODE },<br />
/* Michael Wagner <michael-wagner@gmx.de> */<br />
{ "4MBOL&S", "7521 *", "REV. A0", "", 0 },<br />
/* Alexander Wirt */<br />
...<br />
<br />
Add a new entry using the same format as the others. The first four fields identify your machine and are provided by:<br />
<br />
# s2ram -i<br />
<br />
E.g.:<br />
<br />
sys_vendor = "Acer, inc."<br />
sys_product = "Aspire 1640 "<br />
sys_version = "Not Applicable"<br />
bios_version = "3A05"<br />
<br />
Copy these values between the first four sets of quotes. The fifth field identifies which tricks are needed for your machine, seperate each of the tricks with a | character, like the other lines in the file. If no tricks were required, set it to 0.<br />
<br />
Now force a recompilation and reinstallation of uswsusp with makepkg -efi (The -e prevents makepkg from overwriting your customized whitelist.c). Your machine should now suspend properly with a plain:<br />
<br />
# s2ram<br />
<br />
You can now report your identification strings and any tricks required to the suspend-devel@lists.sourceforge.net mailing list. Please specify always that everything works both from X and from the plain console.<br />
<br />
=The hibernate-script and suspension to ram=<br />
<br />
The hibernate-script, developed in the field of the tuxonice project for [[Suspend to Disk]], can be used also to suspend your machine to ram. Actually, he can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the s2ram seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to ram without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to ram is to use it to call s2ram.<br />
<br />
You can edit /etc/hibernate/hibernate.conf to select ususpend-ram.conf as the default action called by:<br />
<br />
# hibernate<br />
<br />
Just put the following as the first uncommented line:<br />
<br />
TryMethod ususpend-ram.conf<br />
<br />
However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-ram.conf<br />
<br />
Now you should configure the script. Please note that the options that you put in /etc/hibernate/common.conf will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in /etc/hibernate/ususpend-ram.conf will be used only when you suspend to ram with the s2ram method.<br />
<br />
The hibernate-script options are exhaustively described in the man page hibernate.conf.<br />
<br />
First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is /etc/hibernate/blacklisted-modules.<br />
<br />
If you discover that a module is guilty, you should report this to the suspend-devel@lists.sourceforge.net, so that the bad behaviour of the module can be fixed.<br />
<br />
May be also that your display is the guilty and that the tricks provided by s2ram are not enough. The hibernate-script has some further tricks:<br />
<br />
The relevant block of options is the following:<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
However, most of these tricks are already attempted by s2ram and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines:<br />
<br />
EnableVbetool yes<br />
RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
<br />
Please note that, while s2ram uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the --vbe_save s2ram option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command:<br />
<br />
# vbetool vbestate save > /var/lib/vbetool/vbestate<br />
<br />
The second peculiar trick (very often required!) is to uncomment the following line:<br />
<br />
SwitchToTextMode yes<br />
<br />
The script will switch from X to console before suspension and back to X after a successful resuming.<br />
<br />
Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems.<br />
<br />
The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages.<br />
<br />
=s2both=<br />
You can also suspend your machine both to disk and to ram. This is documented in [[Suspend to Disk#Combining suspend to disk with suspend to RAM|a specific section of the wiki page about suspension to disk]].<br />
<br />
=Automatic Suspend and Wakeup=<br />
<br />
Once you have suspend to ram working, you will probably want it to happend automatically e.g., when you close the laptop lid.<br />
<br />
There are several ways to do this. The easiest is to use a high-level power management tool such as KDE's PowerDevil. Another is to create your own ACPI event handler scripts.<br />
<br />
==Automatic Suspend, the Hard Way==<br />
<br />
ACPI events are managed by configuration files in /etc/acpi/events/. (The laptop-mode-tools package contains some examples). A default configuration file called 'anything' is provided by the acpid package, which runs /etc/acpi/handler.sh on every event.<br />
<br />
An simple event configuration file to manage the opening and closing of a laptop lid (that could be called /etc/acpi/events/lid) looks like this:<br />
<br />
event=button[ /]lid<br />
action=/etc/acpi/actions/lid_handler.sh %e<br />
<br />
The first line specifies the names of the events applicable to this file with a regexp. You can get the names of events by enabling event logging in acpid and looking at /var/log/acpid. <br />
<br />
The second line specifies an executable to be run when an applicable event occurs. The '%e' is a variable containing arguments that the event provides. It's a good idea to provide them to the program.<br />
<br />
It's customary to put handling programs in /etc/acpi/actions/. A possible implementation of lid_handler.sh in the previous example could be:<br />
<br />
#!/bin/sh<br />
# check if the lid is open or closed, using the /proc file<br />
if grep closed /proc/acpi/button/lid/LID/state >/dev/null ; then<br />
# if the lid is now closed, save the network state and suspend to ram<br />
netcfg all-suspend<br />
pm-suspend<br />
else<br />
# if the lid is now open, restore the network state.<br />
# (if we are running, a wakeup has already occured!)<br />
netcfg all-resume<br />
fi<br />
<br />
With some basic knowledge of shell scripting, you have a lot of possibilities.<br />
<br />
==Controlling Wakeup ==<br />
<br />
The ACPI events that trigger wakeup are controlled through the procfile /proc/acpi/wakeup. An example output is:<br />
<br />
root@hex in /proc/acpi $ cat wakeup<br />
Device S-state Status Sysfs node<br />
LID S3 *enabled<br />
PBTN S4 *enabled<br />
MBTN S5 enabled<br />
PCI0 S3 disabled no-bus:pci0000:00<br />
USB0 S0 disabled pci:0000:00:1d.0<br />
USB1 S0 disabled pci:0000:00:1d.1<br />
USB2 S0 disabled pci:0000:00:1d.2<br />
USB3 S0 disabled pci:0000:00:1d.3<br />
EHCI S0 disabled pci:0000:00:1d.7<br />
AZAL S3 disabled pci:0000:00:1b.0<br />
PCIE S4 disabled pci:0000:00:1e.0<br />
RP01 S4 disabled pci:0000:00:1c.0<br />
RP02 S3 disabled<br />
RP03 S3 disabled<br />
RP04 S3 disabled pci:0000:00:1c.3<br />
RP05 S3 disabled<br />
RP06 S3 disabled<br />
<br />
To toggle whether an event will trigger a wakeup, pipe its name into the /proc/acpi/wakeup. (Note that every name in the file must have 4 letters, so if it is shorter e.g. LID, it needs be prepended with spaces). So to prevent opening the laptop lid from triggering a wakeup, you could do:<br />
<br />
root@hex in /proc/acpi $ echo " LID" > wakeup<br />
root@hex in /proc/acpi $ cat wakeup<br />
Device S-state Status Sysfs node<br />
LID S3 *disabled<br />
PBTN S4 *disabled<br />
MBTN S5 disabled<br />
PCI0 S3 disabled no-bus:pci0000:00<br />
...<br />
<br />
Another thing to note is that the PBTN and MBTN events were also toggle with the LID event. Sometimes events are linked, so that all of them will be enable and disabled in unison. Checking the 'dmesg' command can confirm this:<br />
<br />
root@hex in /proc/acpi $ dmesg<br />
...<br />
ACPI: 'PBTN' and 'LID' have the same GPE, can't disable/enable one seperately<br />
ACPI: 'MBTN' and 'LID' have the same GPE, can't disable/enable one seperately<br />
<br />
This may not actually affect the other events. On a Dell Inspiron 6400, for example, the power button always triggers a wake up. Your mileage may vary.<br />
<br />
None of this will persist between boots, so you might want to add the echo command to /etc/rc.local so it is executed on every boot:<br />
<br />
# disable the laptop lid switch<br />
echo " LID" > /proc/acpi/wakeup</div>Samwisehttps://wiki.archlinux.org/index.php?title=Suspending_to_RAM_with_hibernate-script&diff=69467Suspending to RAM with hibernate-script2009-05-26T03:53:53Z<p>Samwise: fixed typos</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
====Overview====<br />
In this article we will explain how to accomplish a successful suspension to ram: all the processes are stopped and the current state of your machine is saved to ram. All the devices enter a low-consumption state and it will be very fast to resume the machine.<br />
Suspension to RAM is an acpi state, but the operation is almost never as simple as telling the machine to enter that state. The vast majority of laptops require additional operations and tricks. However, since this is quite an important feature for laptop users, it is worth spending some hours in finding the working combinations of tricks for your machine.<br />
<br />
====Different Methods of Suspending to RAM====<br />
There is an application, called s2ram, which contains a "whitelist" of known laptop models and, according to what has been reported by other owners of these laptops, tries to do the right things for that specific laptop. The whitelisted laptops can therefore use s2ram to suspend to ram "out of the box". Non-whitelisted laptops need to try different command line options of s2ram in order to determine - by trial and error - the appropriate "tricks" needed to make suspend and resume work. Your experience, if reported to the s2ram developers, will contribute to whitelist your machine in the next release of s2ram.<br />
<br />
However, s2ram is not the only resource: the hibernate-script, which is commonly used to accomplish [[Suspend to Disk]] , supports also suspension to RAM and proposes some further tricks which could convince your machine to suspend to ram and resume properly. Moreover, the hibernate-script can automatize other useful operations which you could want/need to do before suspension or after resuming from suspension to ram.<br />
<br />
Thus, the first part of this article will be devoted to s2ram. The second will discuss the use of the hibernate-script in suspension to ram. In particular, we will see how the hibernate-script can be used to suspend to ram your system just with the s2ram, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to ram and to disk.<br />
<br />
===s2ram===<br />
<br />
The s2ram utility is part of the uswsusp collection, which includes also some goodies relative to [[Suspend to Disk]] . You can find uswsusp in the community repositories.<br />
<br />
Read the notes provided by pacman during the ''uswsusp'' package installation. In essence, you will need to:<br />
* edit /etc/suspend.conf to specify the resume device<br />
resume device = /dev/sd''XY''<br />
* update /etc/mkinitcpio.conf to include the ''uresume'' hook<br />
HOOKS="base udev autodetect pata scsi sata ''uresume'' filesystems"<br />
* rebuild the ramdisk<br />
mkinitcpio -p kernel26<br />
<br />
=====Testing=====<br />
After installing the uswsusp package, check to see whether s2ram recognizes your machine:<br />
<br />
# s2ram -n<br />
<br />
If you see a line that says "Machine matched entry #", then your machine is already whitelisted. You SHOULD be able to suspend and resume properly by simply running s2ram:<br />
<br />
# s2ram<br />
<br />
Please note that the way to trigger resume from a suspended to RAM machine depends from your BIOS settings and is not predictable in general (sometimes it is enough to press a key whatsoever). If s2ram seems to work, but something goes wrong in the suspension cycle, then some driver or some process is causing problems and you should look at the hibernate section to see how the hibernate-script can help you. In the worst case, your machine has been erroneously whitelisted due to an inadequate report from another owner of the same machine. You should then report your case to the suspend-devel@lists.sourceforge.net, so that the previous mistaken report can stand corrected. In this case, you should quote the identification strings provided by s2ram -i.<br />
<br />
If s2ram doesn't match your machine to an entry in its whitelist, it will output some general purpose identification strings for your machine (the same as those provided s2ram -i). In this case, you will have to force s2ram to suspend your machine by using s2ram -f.<br />
<br />
<br />
If '''s2ram -f''' doesn't work, try the different workarounds offered by s2ram. Run s2ram -h to get a list of the possible options:<br />
# s2ram -h<br />
Usage: s2ram [-nhi] [-fspmrav]<br />
<br />
Options:<br />
-h, --help: this text.<br />
-n, --test: test if the machine is in the database.<br />
returns 0 if known and supported<br />
-i, --identify: prints a string that identifies the machine.<br />
-f, --force: force suspending, even on unknown machines.<br />
<br />
The following options are only available with -f/--force:<br />
-s, --vbe_save: save VBE state before suspending and restore after resume.<br />
-p, --vbe_post: VBE POST the graphics card after resume<br />
-m, --vbe_mode: get VBE mode before suspend and set it after resume<br />
-r, --radeontool: turn off the backlight on radeons before suspending.<br />
-a, --acpi_sleep: set the acpi_sleep parameter before suspend<br />
1=s3_bios, 2=s3_mode, 3=both<br />
-v, --pci_save: save the PCI config space for the VGA card.<br />
<br />
Try the following variations:<br />
s2ram -f -a 1<br />
s2ram -f -a 2<br />
s2ram -f -a 3<br />
s2ram -f -p -m<br />
s2ram -f -p -s<br />
s2ram -f -m<br />
s2ram -f -s<br />
s2ram -f -p<br />
s2ram -f -a 1 -m<br />
s2ram -f -a 1 -s<br />
<br />
If none of those combinations work, start again but add the "-v" switch.<br />
<br />
Note that mixing the "-a" options and the vbetool options ("-p", "-m", "-s")<br />
is normally only a measure of last resort, it usually does not make much<br />
sense.<br />
<br />
<br />
If you find several combinations that work (e.g. "s2ram -f -a 3" and "s2ram -f -p -m" both work on your machine),<br />
the in-kernel method ("-a") should be preferred over the userspace methods ("-p", "-m" and "-s").<br />
<br />
Verify all combinations in both cases when reporting success to the s2ram developers:<br />
* when issuing s2ram from console<br />
* when issuing s2ram from X<br />
<br />
<br />
You should really try ANY combination of these options (the only exception is the radeontool one, which can be useuful only if you have a radeon card), until you find a working combination. When you find a working combination, try to reduce it (that is try to see if any of the options are redundant). With any working combination of options, it is crucial to verify that suspension and resuming work fine both if you suspend from X and if you suspend from the plain console. Actually, in many setups the most tricky thing is to suspend and resume properly from the console. In the best case, s2ram -f is enough: this means that your machine does not require any trick to properly suspend and resume.<br />
<br />
There is a trick which does not correspond to a command line option, because it requires additional operations from you. It is marked with NOFB in the whitelist and used for those laptops which suspend and resume properly only if no framebuffer is used. If you verify that no command line option of s2ram works, you can try to disable the framebuffer. In order to do this, you need to edit your grub configuration /boot/grub/menu.lst (or the corresponding lilo file), remove the vga=<foo> value from the kernel line and reboot. This at least if you use the VESAFB framebufeer (as in the arch default kernel). If you use a different framebuffer driver, refer to the documentation of the driver to see how to disable it. <br />
<br />
After you have identified the shortest working combination of options, you should do two things. First, you will want to modify the whitelist for your local copy of s2ram to allow your machine to suspend and resume without any special options. Second, you will want to let the developers of s2ram know what options are needed for your machine so it can be added to the whitelist for future releases s2ram.<br />
<br />
Finally, it may happen that no trick makes s2ram work. In this case - before giving up - you can use some last-resort tricks provided by the hibernation-script discussed later in this article.<br />
<br />
=====Whitelisting=====<br />
To add your machine to the local whitelist for s2ram, you need to customize the package from [[ABS]]. Copy the /var/abs/community/system/uswsusp folder somewhere then run makepkg -o to download the sources. After this, edit the file src/suspend-0.8/whitelist.c<br />
<br />
You will see something like this: <br />
<br />
struct machine_entry whitelist[] = {<br />
{ "IBM", "", "ThinkPad X32", "", RADEON_OFF|S3_BIOS|S3_MODE },<br />
/* Michael Wagner <michael-wagner@gmx.de> */<br />
{ "4MBOL&S", "7521 *", "REV. A0", "", 0 },<br />
/* Alexander Wirt */<br />
...<br />
<br />
Add a new entry using the same format as the others. The first four fields identify your machine and are provided by:<br />
<br />
# s2ram -i<br />
<br />
E.g.:<br />
<br />
sys_vendor = "Acer, inc."<br />
sys_product = "Aspire 1640 "<br />
sys_version = "Not Applicable"<br />
bios_version = "3A05"<br />
<br />
Copy these values between the first four sets of quotes. The fifth field identifies which tricks are needed for your machine, seperate each of the tricks with a | character, like the other lines in the file. If no tricks were required, set it to 0.<br />
<br />
Now force a recompilation and reinstallation of uswsusp with makepkg -efi (The -e prevents makepkg from overwriting your customized whitelist.c). Your machine should now suspend properly with a plain:<br />
<br />
# s2ram<br />
<br />
You can now report your identification strings and any tricks required to the suspend-devel@lists.sourceforge.net mailing list. Please specify always that everything works both from X and from the plain console.<br />
<br />
=The hibernate-script and suspension to ram=<br />
<br />
The hibernate-script, developed in the field of the tuxonice project for [[Suspend to Disk]], can be used also to suspend your machine to ram. Actually, he can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the s2ram seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to ram without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to ram is to use it to call s2ram.<br />
<br />
You can edit /etc/hibernate/hibernate.conf to select ususpend-ram.conf as the default action called by:<br />
<br />
# hibernate<br />
<br />
Just put the following as the first uncommented line:<br />
<br />
TryMethod ususpend-ram.conf<br />
<br />
However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-ram.conf<br />
<br />
Now you should configure the script. Please note that the options that you put in /etc/hibernate/common.conf will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in /etc/hibernate/ususpend-ram.conf will be used only when you suspend to ram with the s2ram method.<br />
<br />
The hibernate-script options are exhaustively described in the man page hibernate.conf.<br />
<br />
First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is /etc/hibernate/blacklisted-modules.<br />
<br />
If you discover that a module is guilty, you should report this to the suspend-devel@lists.sourceforge.net, so that the bad behaviour of the module can be fixed.<br />
<br />
May be also that your display is the guilty and that the tricks provided by s2ram are not enough. The hibernate-script has some further tricks:<br />
<br />
The relevant block of options is the following:<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
However, most of these tricks are already attempted by s2ram and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines:<br />
<br />
EnableVbetool yes<br />
RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
<br />
Please note that, while s2ram uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the --vbe_save s2ram option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command:<br />
<br />
# vbetool vbestate save > /var/lib/vbetool/vbestate<br />
<br />
The second peculiar trick (very often required!) is to uncomment the following line:<br />
<br />
SwitchToTextMode yes<br />
<br />
The script will switch from X to console before suspension and back to X after a successful resuming.<br />
<br />
Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems.<br />
<br />
The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages.<br />
<br />
=s2both=<br />
You can also suspend your machine both to disk and to ram. This is documented in [[Suspend to Disk#Combining suspend to disk with suspend to RAM|a specific section of the wiki page about suspension to disk]].<br />
<br />
=Automatic Suspend and Wakeup=<br />
<br />
Once you have suspend to ram working, you will probably want it to happend automatically e.g., when you close the laptop lid.<br />
<br />
There are several ways to do this. The easiest is to use a high-level power management tool such as KDE's PowerDevil. Another is to create your own ACPI event handler scripts.<br />
<br />
==Automatic Suspend, the Hard Way==<br />
<br />
ACPI events are managed by configuration files in /etc/acpi/events/. (The laptop-mode-tools package contains some examples). A default configuration file called 'anything' is provided by the acpid package.<br />
<br />
An simple event configuration file to manage the opening and closing of a laptop lid (that could be called /etc/acpi/events/lid) looks like this:<br />
<br />
event=button[ /]lid<br />
action=/etc/acpi/actions/lid_handler.sh %e<br />
<br />
The first line specifies the names of the events applicable to this file with a regexp. You can get the names of events by enabling event logging in acpid and looking at /var/log/acpid. <br />
<br />
The second line specifies an executable to be run when an applicable event occurs. The '%e' is a variable containing arguments that the event provides. It's a good idea to provide them to the program.<br />
<br />
It's customary to put handling programs in /etc/acpi/actions/. A possible implementation of lid_handler.sh in the previous example could be:<br />
<br />
#!/bin/sh<br />
<br />
# check if the lid is open or closed, using the /proc file<br />
if grep closed /proc/acpi/button/lid/LID/state >/dev/null ; then<br />
# if the lid is now closed, save the network state and suspend to ram<br />
netcfg all-suspend<br />
pm-suspend<br />
else<br />
# if the lid is now open, restore the network state.<br />
# (if we are running, a wakeup has already occured!)<br />
netcfg all-resume<br />
fi<br />
<br />
With some basic knowledge of shell scripting, you have a lot of possibilities.<br />
<br />
==Controlling Wakeup ==<br />
<br />
The ACPI events that trigger wakeup are controlled through the procfile /proc/acpi/wakeup. An example output is:<br />
<br />
root@hex in /proc/acpi $ cat wakeup<br />
Device S-state Status Sysfs node<br />
LID S3 *enabled<br />
PBTN S4 *enabled<br />
MBTN S5 enabled<br />
PCI0 S3 disabled no-bus:pci0000:00<br />
USB0 S0 disabled pci:0000:00:1d.0<br />
USB1 S0 disabled pci:0000:00:1d.1<br />
USB2 S0 disabled pci:0000:00:1d.2<br />
USB3 S0 disabled pci:0000:00:1d.3<br />
EHCI S0 disabled pci:0000:00:1d.7<br />
AZAL S3 disabled pci:0000:00:1b.0<br />
PCIE S4 disabled pci:0000:00:1e.0<br />
RP01 S4 disabled pci:0000:00:1c.0<br />
RP02 S3 disabled<br />
RP03 S3 disabled<br />
RP04 S3 disabled pci:0000:00:1c.3<br />
RP05 S3 disabled<br />
RP06 S3 disabled<br />
<br />
To toggle whether an event will trigger a wakeup, pipe its name into the /proc/acpi/wakeup. (Note that every name in the file must have 4 letters, so if it is shorter e.g. LID, it needs be prepended with spaces). So to prevent opening the laptop lid from triggering a wakeup, you could do:<br />
<br />
root@hex in /proc/acpi $ echo " LID" > wakeup<br />
root@hex in /proc/acpi $ cat wakeup<br />
Device S-state Status Sysfs node<br />
LID S3 *disabled<br />
PBTN S4 *disabled<br />
MBTN S5 disabled<br />
PCI0 S3 disabled no-bus:pci0000:00<br />
...<br />
<br />
Another thing to note is that the PBTN and MBTN events were also toggle with the LID event. Sometimes events are linked, so that all of them will be enable and disabled in unison. Checking the 'dmesg' command can confirm this:<br />
<br />
root@hex in /proc/acpi $ dmesg<br />
...<br />
ACPI: 'PBTN' and 'LID' have the same GPE, can't disable/enable one seperately<br />
ACPI: 'MBTN' and 'LID' have the same GPE, can't disable/enable one seperately<br />
<br />
This may not actually affect the other events. On a Dell Inspiron 6400, for example, the power button always triggers a wake up. Your mileage may vary.<br />
<br />
None of this will persist between boots, so you might want to add the echo command to /etc/rc.local so it is executed on every boot:<br />
<br />
# disable the laptop lid switch<br />
echo " LID" > /proc/acpi/wakeup</div>Samwisehttps://wiki.archlinux.org/index.php?title=Suspending_to_RAM_with_hibernate-script&diff=69466Suspending to RAM with hibernate-script2009-05-26T03:51:47Z<p>Samwise: Added section on using acpi to automatically suspend.</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
====Overview====<br />
In this article we will explain how to accomplish a successful suspension to ram: all the processes are stopped and the current state of your machine is saved to ram. All the devices enter a low-consumption state and it will be very fast to resume the machine.<br />
Suspension to RAM is an acpi state, but the operation is almost never as simple as telling the machine to enter that state. The vast majority of laptops require additional operations and tricks. However, since this is quite an important feature for laptop users, it is worth spending some hours in finding the working combinations of tricks for your machine.<br />
<br />
====Different Methods of Suspending to RAM====<br />
There is an application, called s2ram, which contains a "whitelist" of known laptop models and, according to what has been reported by other owners of these laptops, tries to do the right things for that specific laptop. The whitelisted laptops can therefore use s2ram to suspend to ram "out of the box". Non-whitelisted laptops need to try different command line options of s2ram in order to determine - by trial and error - the appropriate "tricks" needed to make suspend and resume work. Your experience, if reported to the s2ram developers, will contribute to whitelist your machine in the next release of s2ram.<br />
<br />
However, s2ram is not the only resource: the hibernate-script, which is commonly used to accomplish [[Suspend to Disk]] , supports also suspension to RAM and proposes some further tricks which could convince your machine to suspend to ram and resume properly. Moreover, the hibernate-script can automatize other useful operations which you could want/need to do before suspension or after resuming from suspension to ram.<br />
<br />
Thus, the first part of this article will be devoted to s2ram. The second will discuss the use of the hibernate-script in suspension to ram. In particular, we will see how the hibernate-script can be used to suspend to ram your system just with the s2ram, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to ram and to disk.<br />
<br />
===s2ram===<br />
<br />
The s2ram utility is part of the uswsusp collection, which includes also some goodies relative to [[Suspend to Disk]] . You can find uswsusp in the community repositories.<br />
<br />
Read the notes provided by pacman during the ''uswsusp'' package installation. In essence, you will need to:<br />
* edit /etc/suspend.conf to specify the resume device<br />
resume device = /dev/sd''XY''<br />
* update /etc/mkinitcpio.conf to include the ''uresume'' hook<br />
HOOKS="base udev autodetect pata scsi sata ''uresume'' filesystems"<br />
* rebuild the ramdisk<br />
mkinitcpio -p kernel26<br />
<br />
=====Testing=====<br />
After installing the uswsusp package, check to see whether s2ram recognizes your machine:<br />
<br />
# s2ram -n<br />
<br />
If you see a line that says "Machine matched entry #", then your machine is already whitelisted. You SHOULD be able to suspend and resume properly by simply running s2ram:<br />
<br />
# s2ram<br />
<br />
Please note that the way to trigger resume from a suspended to RAM machine depends from your BIOS settings and is not predictable in general (sometimes it is enough to press a key whatsoever). If s2ram seems to work, but something goes wrong in the suspension cycle, then some driver or some process is causing problems and you should look at the hibernate section to see how the hibernate-script can help you. In the worst case, your machine has been erroneously whitelisted due to an inadequate report from another owner of the same machine. You should then report your case to the suspend-devel@lists.sourceforge.net, so that the previous mistaken report can stand corrected. In this case, you should quote the identification strings provided by s2ram -i.<br />
<br />
If s2ram doesn't match your machine to an entry in its whitelist, it will output some general purpose identification strings for your machine (the same as those provided s2ram -i). In this case, you will have to force s2ram to suspend your machine by using s2ram -f.<br />
<br />
<br />
If '''s2ram -f''' doesn't work, try the different workarounds offered by s2ram. Run s2ram -h to get a list of the possible options:<br />
# s2ram -h<br />
Usage: s2ram [-nhi] [-fspmrav]<br />
<br />
Options:<br />
-h, --help: this text.<br />
-n, --test: test if the machine is in the database.<br />
returns 0 if known and supported<br />
-i, --identify: prints a string that identifies the machine.<br />
-f, --force: force suspending, even on unknown machines.<br />
<br />
The following options are only available with -f/--force:<br />
-s, --vbe_save: save VBE state before suspending and restore after resume.<br />
-p, --vbe_post: VBE POST the graphics card after resume<br />
-m, --vbe_mode: get VBE mode before suspend and set it after resume<br />
-r, --radeontool: turn off the backlight on radeons before suspending.<br />
-a, --acpi_sleep: set the acpi_sleep parameter before suspend<br />
1=s3_bios, 2=s3_mode, 3=both<br />
-v, --pci_save: save the PCI config space for the VGA card.<br />
<br />
Try the following variations:<br />
s2ram -f -a 1<br />
s2ram -f -a 2<br />
s2ram -f -a 3<br />
s2ram -f -p -m<br />
s2ram -f -p -s<br />
s2ram -f -m<br />
s2ram -f -s<br />
s2ram -f -p<br />
s2ram -f -a 1 -m<br />
s2ram -f -a 1 -s<br />
<br />
If none of those combinations work, start again but add the "-v" switch.<br />
<br />
Note that mixing the "-a" options and the vbetool options ("-p", "-m", "-s")<br />
is normally only a measure of last resort, it usually does not make much<br />
sense.<br />
<br />
<br />
If you find several combinations that work (e.g. "s2ram -f -a 3" and "s2ram -f -p -m" both work on your machine),<br />
the in-kernel method ("-a") should be preferred over the userspace methods ("-p", "-m" and "-s").<br />
<br />
Verify all combinations in both cases when reporting success to the s2ram developers:<br />
* when issuing s2ram from console<br />
* when issuing s2ram from X<br />
<br />
<br />
You should really try ANY combination of these options (the only exception is the radeontool one, which can be useuful only if you have a radeon card), until you find a working combination. When you find a working combination, try to reduce it (that is try to see if any of the options are redundant). With any working combination of options, it is crucial to verify that suspension and resuming work fine both if you suspend from X and if you suspend from the plain console. Actually, in many setups the most tricky thing is to suspend and resume properly from the console. In the best case, s2ram -f is enough: this means that your machine does not require any trick to properly suspend and resume.<br />
<br />
There is a trick which does not correspond to a command line option, because it requires additional operations from you. It is marked with NOFB in the whitelist and used for those laptops which suspend and resume properly only if no framebuffer is used. If you verify that no command line option of s2ram works, you can try to disable the framebuffer. In order to do this, you need to edit your grub configuration /boot/grub/menu.lst (or the corresponding lilo file), remove the vga=<foo> value from the kernel line and reboot. This at least if you use the VESAFB framebufeer (as in the arch default kernel). If you use a different framebuffer driver, refer to the documentation of the driver to see how to disable it. <br />
<br />
After you have identified the shortest working combination of options, you should do two things. First, you will want to modify the whitelist for your local copy of s2ram to allow your machine to suspend and resume without any special options. Second, you will want to let the developers of s2ram know what options are needed for your machine so it can be added to the whitelist for future releases s2ram.<br />
<br />
Finally, it may happen that no trick makes s2ram work. In this case - before giving up - you can use some last-resort tricks provided by the hibernation-script discussed later in this article.<br />
<br />
=====Whitelisting=====<br />
To add your machine to the local whitelist for s2ram, you need to customize the package from [[ABS]]. Copy the /var/abs/community/system/uswsusp folder somewhere then run makepkg -o to download the sources. After this, edit the file src/suspend-0.8/whitelist.c<br />
<br />
You will see something like this: <br />
<br />
struct machine_entry whitelist[] = {<br />
{ "IBM", "", "ThinkPad X32", "", RADEON_OFF|S3_BIOS|S3_MODE },<br />
/* Michael Wagner <michael-wagner@gmx.de> */<br />
{ "4MBOL&S", "7521 *", "REV. A0", "", 0 },<br />
/* Alexander Wirt */<br />
...<br />
<br />
Add a new entry using the same format as the others. The first four fields identify your machine and are provided by:<br />
<br />
# s2ram -i<br />
<br />
E.g.:<br />
<br />
sys_vendor = "Acer, inc."<br />
sys_product = "Aspire 1640 "<br />
sys_version = "Not Applicable"<br />
bios_version = "3A05"<br />
<br />
Copy these values between the first four sets of quotes. The fifth field identifies which tricks are needed for your machine, seperate each of the tricks with a | character, like the other lines in the file. If no tricks were required, set it to 0.<br />
<br />
Now force a recompilation and reinstallation of uswsusp with makepkg -efi (The -e prevents makepkg from overwriting your customized whitelist.c). Your machine should now suspend properly with a plain:<br />
<br />
# s2ram<br />
<br />
You can now report your identification strings and any tricks required to the suspend-devel@lists.sourceforge.net mailing list. Please specify always that everything works both from X and from the plain console.<br />
<br />
=The hibernate-script and suspension to ram=<br />
<br />
The hibernate-script, developed in the field of the tuxonice project for [[Suspend to Disk]], can be used also to suspend your machine to ram. Actually, he can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the s2ram seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to ram without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to ram is to use it to call s2ram.<br />
<br />
You can edit /etc/hibernate/hibernate.conf to select ususpend-ram.conf as the default action called by:<br />
<br />
# hibernate<br />
<br />
Just put the following as the first uncommented line:<br />
<br />
TryMethod ususpend-ram.conf<br />
<br />
However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-ram.conf<br />
<br />
Now you should configure the script. Please note that the options that you put in /etc/hibernate/common.conf will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in /etc/hibernate/ususpend-ram.conf will be used only when you suspend to ram with the s2ram method.<br />
<br />
The hibernate-script options are exhaustively described in the man page hibernate.conf.<br />
<br />
First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is /etc/hibernate/blacklisted-modules.<br />
<br />
If you discover that a module is guilty, you should report this to the suspend-devel@lists.sourceforge.net, so that the bad behaviour of the module can be fixed.<br />
<br />
May be also that your display is the guilty and that the tricks provided by s2ram are not enough. The hibernate-script has some further tricks:<br />
<br />
The relevant block of options is the following:<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
However, most of these tricks are already attempted by s2ram and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines:<br />
<br />
EnableVbetool yes<br />
RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
<br />
Please note that, while s2ram uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the --vbe_save s2ram option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command:<br />
<br />
# vbetool vbestate save > /var/lib/vbetool/vbestate<br />
<br />
The second peculiar trick (very often required!) is to uncomment the following line:<br />
<br />
SwitchToTextMode yes<br />
<br />
The script will switch from X to console before suspension and back to X after a successful resuming.<br />
<br />
Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems.<br />
<br />
The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages.<br />
<br />
=s2both=<br />
You can also suspend your machine both to disk and to ram. This is documented in [[Suspend to Disk#Combining suspend to disk with suspend to RAM|a specific section of the wiki page about suspension to disk]].<br />
<br />
=Automatic Suspend and Wakeup=<br />
<br />
Once you have suspend to ram working, you will probably want it to happend automatically e.g., when you close the laptop lid.<br />
<br />
There are several ways to do this. The easiest is to use a high-level power management tool such as KDE's PowerDevil. Another is to create your own ACPI event handler scripts.<br />
<br />
==Automatic Suspend, the Hard Way==<br />
<br />
ACPI events are managed by configuration files in /etc/acpi/events/. (The laptop-mode-tools package contains some examples). A default configuration file called 'anything' is provided by the acpid package.<br />
<br />
An simple event configuration file to manage the opening and closing of a laptop lid (/etc/acpi/events/lid) looks like this:<br />
<br />
event=button[ /]lid<br />
action=/etc/acpi/actions/lid_handler.sh %e<br />
<br />
The first line specifies the names of the events applicable to this file with a regexp. You can get the names of events by enabling logging in acpid and looking at /var/log/acpid. <br />
<br />
The second line specifies an executable to be run when an applicable event occurs. The '%e' is a variable containing arguments that the event provides. It's a good idea to provided them to the program.<br />
<br />
It's customary to put handling programs in /etc/acpi/actions/. A possible implementation of lid_handler.sh in the previous example could be:<br />
<br />
#!/bin/sh<br />
<br />
# check if the lid is open or closed, using the /proc file<br />
if grep closed /proc/acpi/button/lid/LID/state >/dev/null ; then<br />
# if the lid is now closed, save the network state and suspend to ram<br />
netcfg all-suspend<br />
pm-suspend<br />
else<br />
# if the lid is now open, restore the network state.<br />
# (if we are running, a wakeup has already occured!)<br />
netcfg all-resume<br />
fi<br />
<br />
With some knowledge of shell scripting, you have a lot of possibilities.<br />
<br />
==Controlling Wakeup ==<br />
<br />
The ACPI events that trigger wakeup are controlled through the procfile /proc/acpi/wakeup. An example output is:<br />
<br />
root@hex in /proc/acpi $ cat wakeup<br />
Device S-state Status Sysfs node<br />
LID S3 *enabled<br />
PBTN S4 *enabled<br />
MBTN S5 enabled<br />
PCI0 S3 disabled no-bus:pci0000:00<br />
USB0 S0 disabled pci:0000:00:1d.0<br />
USB1 S0 disabled pci:0000:00:1d.1<br />
USB2 S0 disabled pci:0000:00:1d.2<br />
USB3 S0 disabled pci:0000:00:1d.3<br />
EHCI S0 disabled pci:0000:00:1d.7<br />
AZAL S3 disabled pci:0000:00:1b.0<br />
PCIE S4 disabled pci:0000:00:1e.0<br />
RP01 S4 disabled pci:0000:00:1c.0<br />
RP02 S3 disabled<br />
RP03 S3 disabled<br />
RP04 S3 disabled pci:0000:00:1c.3<br />
RP05 S3 disabled<br />
RP06 S3 disabled<br />
<br />
To toggle whether an event will trigger a wakeup, pipe its name into the /proc/acpi/wakeup. (Note that every name in the file must have 4 letters, so if it is shorter e.g. LID, it needs be prepended with spaces). So to prevent opening the laptop lid from triggering a wakeup, you could do:<br />
<br />
root@hex in /proc/acpi $ echo " LID" > wakeup<br />
root@hex in /proc/acpi $ cat wakeup<br />
Device S-state Status Sysfs node<br />
LID S3 *disabled<br />
PBTN S4 *disabled<br />
MBTN S5 disabled<br />
PCI0 S3 disabled no-bus:pci0000:00<br />
...<br />
<br />
Another thing to note is that the PBTN and MBTN events were also toggle with the LID event. Sometimes events are linked, so that all of them will be enable and disabled in unison. Checking the 'dmesg' command can confirm this:<br />
<br />
root@hex in /proc/acpi $ dmesg<br />
...<br />
ACPI: 'PBTN' and 'LID' have the same GPE, can't disable/enable one seperately<br />
ACPI: 'MBTN' and 'LID' have the same GPE, can't disable/enable one seperately<br />
<br />
This may not actually affect the other events. On a Dell Inspiron 6400, for example, the power button always triggers a wake up. Your mileage may vary.<br />
<br />
None of this will persist between boots, so you might want to add the echo command to /etc/rc.local so it is executed on every boot:<br />
<br />
# disable the laptop lid switch<br />
echo " LID" > /proc/acpi/wakeup</div>Samwisehttps://wiki.archlinux.org/index.php?title=Suspending_to_RAM_with_hibernate-script&diff=69465Suspending to RAM with hibernate-script2009-05-26T03:32:23Z<p>Samwise: Added section on controlling wakeup events.</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
====Overview====<br />
In this article we will explain how to accomplish a successful suspension to ram: all the processes are stopped and the current state of your machine is saved to ram. All the devices enter a low-consumption state and it will be very fast to resume the machine.<br />
Suspension to RAM is an acpi state, but the operation is almost never as simple as telling the machine to enter that state. The vast majority of laptops require additional operations and tricks. However, since this is quite an important feature for laptop users, it is worth spending some hours in finding the working combinations of tricks for your machine.<br />
<br />
====Different Methods of Suspending to RAM====<br />
There is an application, called s2ram, which contains a "whitelist" of known laptop models and, according to what has been reported by other owners of these laptops, tries to do the right things for that specific laptop. The whitelisted laptops can therefore use s2ram to suspend to ram "out of the box". Non-whitelisted laptops need to try different command line options of s2ram in order to determine - by trial and error - the appropriate "tricks" needed to make suspend and resume work. Your experience, if reported to the s2ram developers, will contribute to whitelist your machine in the next release of s2ram.<br />
<br />
However, s2ram is not the only resource: the hibernate-script, which is commonly used to accomplish [[Suspend to Disk]] , supports also suspension to RAM and proposes some further tricks which could convince your machine to suspend to ram and resume properly. Moreover, the hibernate-script can automatize other useful operations which you could want/need to do before suspension or after resuming from suspension to ram.<br />
<br />
Thus, the first part of this article will be devoted to s2ram. The second will discuss the use of the hibernate-script in suspension to ram. In particular, we will see how the hibernate-script can be used to suspend to ram your system just with the s2ram, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to ram and to disk.<br />
<br />
===s2ram===<br />
<br />
The s2ram utility is part of the uswsusp collection, which includes also some goodies relative to [[Suspend to Disk]] . You can find uswsusp in the community repositories.<br />
<br />
Read the notes provided by pacman during the ''uswsusp'' package installation. In essence, you will need to:<br />
* edit /etc/suspend.conf to specify the resume device<br />
resume device = /dev/sd''XY''<br />
* update /etc/mkinitcpio.conf to include the ''uresume'' hook<br />
HOOKS="base udev autodetect pata scsi sata ''uresume'' filesystems"<br />
* rebuild the ramdisk<br />
mkinitcpio -p kernel26<br />
<br />
=====Testing=====<br />
After installing the uswsusp package, check to see whether s2ram recognizes your machine:<br />
<br />
# s2ram -n<br />
<br />
If you see a line that says "Machine matched entry #", then your machine is already whitelisted. You SHOULD be able to suspend and resume properly by simply running s2ram:<br />
<br />
# s2ram<br />
<br />
Please note that the way to trigger resume from a suspended to RAM machine depends from your BIOS settings and is not predictable in general (sometimes it is enough to press a key whatsoever). If s2ram seems to work, but something goes wrong in the suspension cycle, then some driver or some process is causing problems and you should look at the hibernate section to see how the hibernate-script can help you. In the worst case, your machine has been erroneously whitelisted due to an inadequate report from another owner of the same machine. You should then report your case to the suspend-devel@lists.sourceforge.net, so that the previous mistaken report can stand corrected. In this case, you should quote the identification strings provided by s2ram -i.<br />
<br />
If s2ram doesn't match your machine to an entry in its whitelist, it will output some general purpose identification strings for your machine (the same as those provided s2ram -i). In this case, you will have to force s2ram to suspend your machine by using s2ram -f.<br />
<br />
<br />
If '''s2ram -f''' doesn't work, try the different workarounds offered by s2ram. Run s2ram -h to get a list of the possible options:<br />
# s2ram -h<br />
Usage: s2ram [-nhi] [-fspmrav]<br />
<br />
Options:<br />
-h, --help: this text.<br />
-n, --test: test if the machine is in the database.<br />
returns 0 if known and supported<br />
-i, --identify: prints a string that identifies the machine.<br />
-f, --force: force suspending, even on unknown machines.<br />
<br />
The following options are only available with -f/--force:<br />
-s, --vbe_save: save VBE state before suspending and restore after resume.<br />
-p, --vbe_post: VBE POST the graphics card after resume<br />
-m, --vbe_mode: get VBE mode before suspend and set it after resume<br />
-r, --radeontool: turn off the backlight on radeons before suspending.<br />
-a, --acpi_sleep: set the acpi_sleep parameter before suspend<br />
1=s3_bios, 2=s3_mode, 3=both<br />
-v, --pci_save: save the PCI config space for the VGA card.<br />
<br />
Try the following variations:<br />
s2ram -f -a 1<br />
s2ram -f -a 2<br />
s2ram -f -a 3<br />
s2ram -f -p -m<br />
s2ram -f -p -s<br />
s2ram -f -m<br />
s2ram -f -s<br />
s2ram -f -p<br />
s2ram -f -a 1 -m<br />
s2ram -f -a 1 -s<br />
<br />
If none of those combinations work, start again but add the "-v" switch.<br />
<br />
Note that mixing the "-a" options and the vbetool options ("-p", "-m", "-s")<br />
is normally only a measure of last resort, it usually does not make much<br />
sense.<br />
<br />
<br />
If you find several combinations that work (e.g. "s2ram -f -a 3" and "s2ram -f -p -m" both work on your machine),<br />
the in-kernel method ("-a") should be preferred over the userspace methods ("-p", "-m" and "-s").<br />
<br />
Verify all combinations in both cases when reporting success to the s2ram developers:<br />
* when issuing s2ram from console<br />
* when issuing s2ram from X<br />
<br />
<br />
You should really try ANY combination of these options (the only exception is the radeontool one, which can be useuful only if you have a radeon card), until you find a working combination. When you find a working combination, try to reduce it (that is try to see if any of the options are redundant). With any working combination of options, it is crucial to verify that suspension and resuming work fine both if you suspend from X and if you suspend from the plain console. Actually, in many setups the most tricky thing is to suspend and resume properly from the console. In the best case, s2ram -f is enough: this means that your machine does not require any trick to properly suspend and resume.<br />
<br />
There is a trick which does not correspond to a command line option, because it requires additional operations from you. It is marked with NOFB in the whitelist and used for those laptops which suspend and resume properly only if no framebuffer is used. If you verify that no command line option of s2ram works, you can try to disable the framebuffer. In order to do this, you need to edit your grub configuration /boot/grub/menu.lst (or the corresponding lilo file), remove the vga=<foo> value from the kernel line and reboot. This at least if you use the VESAFB framebufeer (as in the arch default kernel). If you use a different framebuffer driver, refer to the documentation of the driver to see how to disable it. <br />
<br />
After you have identified the shortest working combination of options, you should do two things. First, you will want to modify the whitelist for your local copy of s2ram to allow your machine to suspend and resume without any special options. Second, you will want to let the developers of s2ram know what options are needed for your machine so it can be added to the whitelist for future releases s2ram.<br />
<br />
Finally, it may happen that no trick makes s2ram work. In this case - before giving up - you can use some last-resort tricks provided by the hibernation-script discussed later in this article.<br />
<br />
=====Whitelisting=====<br />
To add your machine to the local whitelist for s2ram, you need to customize the package from [[ABS]]. Copy the /var/abs/community/system/uswsusp folder somewhere then run makepkg -o to download the sources. After this, edit the file src/suspend-0.8/whitelist.c<br />
<br />
You will see something like this: <br />
<br />
struct machine_entry whitelist[] = {<br />
{ "IBM", "", "ThinkPad X32", "", RADEON_OFF|S3_BIOS|S3_MODE },<br />
/* Michael Wagner <michael-wagner@gmx.de> */<br />
{ "4MBOL&S", "7521 *", "REV. A0", "", 0 },<br />
/* Alexander Wirt */<br />
...<br />
<br />
Add a new entry using the same format as the others. The first four fields identify your machine and are provided by:<br />
<br />
# s2ram -i<br />
<br />
E.g.:<br />
<br />
sys_vendor = "Acer, inc."<br />
sys_product = "Aspire 1640 "<br />
sys_version = "Not Applicable"<br />
bios_version = "3A05"<br />
<br />
Copy these values between the first four sets of quotes. The fifth field identifies which tricks are needed for your machine, seperate each of the tricks with a | character, like the other lines in the file. If no tricks were required, set it to 0.<br />
<br />
Now force a recompilation and reinstallation of uswsusp with makepkg -efi (The -e prevents makepkg from overwriting your customized whitelist.c). Your machine should now suspend properly with a plain:<br />
<br />
# s2ram<br />
<br />
You can now report your identification strings and any tricks required to the suspend-devel@lists.sourceforge.net mailing list. Please specify always that everything works both from X and from the plain console.<br />
<br />
=The hibernate-script and suspension to ram=<br />
<br />
The hibernate-script, developed in the field of the tuxonice project for [[Suspend to Disk]], can be used also to suspend your machine to ram. Actually, he can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the s2ram seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to ram without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to ram is to use it to call s2ram.<br />
<br />
You can edit /etc/hibernate/hibernate.conf to select ususpend-ram.conf as the default action called by:<br />
<br />
# hibernate<br />
<br />
Just put the following as the first uncommented line:<br />
<br />
TryMethod ususpend-ram.conf<br />
<br />
However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-ram.conf<br />
<br />
Now you should configure the script. Please note that the options that you put in /etc/hibernate/common.conf will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in /etc/hibernate/ususpend-ram.conf will be used only when you suspend to ram with the s2ram method.<br />
<br />
The hibernate-script options are exhaustively described in the man page hibernate.conf.<br />
<br />
First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is /etc/hibernate/blacklisted-modules.<br />
<br />
If you discover that a module is guilty, you should report this to the suspend-devel@lists.sourceforge.net, so that the bad behaviour of the module can be fixed.<br />
<br />
May be also that your display is the guilty and that the tricks provided by s2ram are not enough. The hibernate-script has some further tricks:<br />
<br />
The relevant block of options is the following:<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
However, most of these tricks are already attempted by s2ram and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines:<br />
<br />
EnableVbetool yes<br />
RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
<br />
Please note that, while s2ram uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the --vbe_save s2ram option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command:<br />
<br />
# vbetool vbestate save > /var/lib/vbetool/vbestate<br />
<br />
The second peculiar trick (very often required!) is to uncomment the following line:<br />
<br />
SwitchToTextMode yes<br />
<br />
The script will switch from X to console before suspension and back to X after a successful resuming.<br />
<br />
Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems.<br />
<br />
The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages.<br />
<br />
=s2both=<br />
You can also suspend your machine both to disk and to ram. This is documented in [[Suspend to Disk#Combining suspend to disk with suspend to RAM|a specific section of the wiki page about suspension to disk]].<br />
<br />
=Automatic Suspend and Wakeup=<br />
<br />
Once you have suspend to ram working, you will probably want it to happend automatically e.g., when you close the laptop lid.<br />
<br />
There are several ways to do this. The easiest is to use a high-level power management tool such as KDE's PowerDevil. Another is to create your own ACPI event handler scripts.<br />
<br />
==Controlling Wakeup ==<br />
<br />
The ACPI events that trigger wakeup are controlled through the procfile /proc/acpi/wakeup. An example output is:<br />
<br />
root@hex in /proc/acpi $ cat wakeup<br />
Device S-state Status Sysfs node<br />
LID S3 *enabled<br />
PBTN S4 *enabled<br />
MBTN S5 enabled<br />
PCI0 S3 disabled no-bus:pci0000:00<br />
USB0 S0 disabled pci:0000:00:1d.0<br />
USB1 S0 disabled pci:0000:00:1d.1<br />
USB2 S0 disabled pci:0000:00:1d.2<br />
USB3 S0 disabled pci:0000:00:1d.3<br />
EHCI S0 disabled pci:0000:00:1d.7<br />
AZAL S3 disabled pci:0000:00:1b.0<br />
PCIE S4 disabled pci:0000:00:1e.0<br />
RP01 S4 disabled pci:0000:00:1c.0<br />
RP02 S3 disabled<br />
RP03 S3 disabled<br />
RP04 S3 disabled pci:0000:00:1c.3<br />
RP05 S3 disabled<br />
RP06 S3 disabled<br />
<br />
To toggle whether an event will trigger a wakeup, pipe its name into the /proc/acpi/wakeup. (Note that every name in the file must have 4 letters, so if it is shorter e.g. LID, it needs be prepended with spaces)<br />
<br />
root@hex in /proc/acpi $ echo " LID" > wakeup<br />
root@hex in /proc/acpi $ cat wakeup<br />
Device S-state Status Sysfs node<br />
LID S3 *disabled<br />
PBTN S4 *disabled<br />
MBTN S5 disabled<br />
PCI0 S3 disabled no-bus:pci0000:00<br />
...<br />
<br />
Another thing to note is that the PBTN and MBTN events were also toggle with the LID event. Sometimes events are linked, so that all of them will be enable and disabled in unison. Checking the 'dmesg' command can confirm this:<br />
<br />
root@hex in /proc/acpi $ dmesg<br />
...<br />
ACPI: 'PBTN' and 'LID' have the same GPE, can't disable/enable one seperately<br />
ACPI: 'MBTN' and 'LID' have the same GPE, can't disable/enable one seperately<br />
<br />
This may not actually affect the other events. On a Dell Inspiron 6400, for example, the power button always triggers a wake up. Your mileage may vary.<br />
<br />
None of persist between boots, so you might want to add the echo command to /etc/rc.local so it is executed on every boot:<br />
<br />
# disable the laptop lid switch<br />
echo " LID" > /proc/acpi/wakeup</div>Samwisehttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines&diff=54409Lisp package guidelines2008-12-01T02:47:37Z<p>Samwise: </p>
<hr />
<div>[[Category:Package development (English)]]<br />
[[Category:Guidelines (English)]]<br />
== Background ==<br />
<br />
At the moment, there are relatively few lisp packages available in the<br />
Arch repositories. This means that at some point or another, more will<br />
likely appear. It is useful, therefore, to figure out now, while there<br />
are few packages, how they should be packaged. Therefore, this page<br />
stands as a proposed packaging guideline for lisp packages. Keep in<br />
mind, however, that this is a work in progress; if you disagree with<br />
some of the ideas suggested here, feel free to edit the page and<br />
propose something better.<br />
<br />
== Directory Structure ==<br />
<br />
There is at least one package in the base repository (libgpg-error)<br />
that includes lisp files, which are placed in<br />
'''/usr/share/common-lisp/source/gpg-error'''. In keeping with this,<br />
other lisp packages should also place their files in<br />
'''/usr/share/common-lisp/source/'''. Each package should have its own<br />
directory, so as not to clutter up this base directory. The directory<br />
should be the name of the lisp package, not what it's called in the<br />
Arch repository (or AUR). This applies even to single-file packages.<br />
<br />
== ASDF ==<br />
<br />
Try to avoid the usage of ASDF-Install as a means of installing these<br />
system-wide packages.<br />
<br />
ASDF itself may be necessary or helpful as a means of compiling and/or<br />
loading packages. In that case, it is suggested that the directory<br />
used for the central registry (the location of all of the symlinks <br />
to *.asd) be '''/usr/share/common-lisp/systems/'''.<br />
<br />
However, I have observed problems with doing the compilation with asdf<br />
as a part of the package compilation process. However, it does work<br />
during an install, through use of a package.install file. Such a file<br />
might look like this:<br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Of course, for this example to work, there needs to be a symlink to<br />
package.asd in the asdf system directory. During package compilation,<br />
a stanza such as this will do the trick...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...where ''$_lispdir'' is '''${startdir}/pkg/usr/share/common-lisp'''.<br />
By linking to a relative, rather than an absolute, path, it's possible<br />
to guarantee that the link will not break post-install.<br />
<br />
== Lisp-specific packaging ==<br />
<br />
When possible, do not make packages specific to a single lisp<br />
implementation; try to be as cross-platform as the package itself will<br />
allow. If, however, the package is specifically designed for a single<br />
lisp implementation (i.e., the developers haven't gotten around to<br />
adding support for others yet, or the package's purpose is<br />
specifically to provide a capability that is built in to another lisp<br />
implementation), it is appropriate to make your Arch package<br />
lisp-specific.<br />
<br />
To avoid making packages implementation-specific, ideally all<br />
implementation packages (SBCL, cmucl, clisp) would be built with the<br />
PKGBUILD field '''common-lisp'''. However, that's not the case (and<br />
that would likely cause problems for people who prefer to have<br />
multiple lisps at their fingertips). In the meantime, you could (a)<br />
not make your package depend on *any* lisp and include a statement in<br />
the package.install file telling folks to make sure they have a lisp<br />
installed (not ideal), or (b) Take direction from the ''sbcl''<br />
PKGBUILD and include a conditional statement to figure out which lisp<br />
is needed (which is hackish and, again, far from ideal). Other ideas<br />
are welcome.<br />
<br />
Also note that if ASDF is needed to install/compile/load the package,<br />
things could potentially get awkward as far as dependencies go, since<br />
SBCL comes with asdf installed, clisp does not but there is an AUR<br />
package, and CMUCL may or may not have it (the author of this doc.<br />
knows next to nothing about CMUCL; sorry).<br />
<br />
People currently maintaining lisp-specific packages that don't need to<br />
be lisp-specific should consider doing at least one of the following:<br />
<br />
* Editing their PKGBUILD(s) to be cross-platform, provided someone else is not already maintaining the same package for a different lisp.<br />
<br />
* Offering to take over maintenance or help with maintenance of the same package for a different lisp, and then combining them into a single package.<br />
<br />
* Offering up their package to the maintainer of a different lisp's version of the same package, so as to allow that person to combine them into a single package.<br />
<br />
(Note that joyfulgirl, the author of this doc., currently maintains<br />
clisp versions of cl-ppcre and of stumpwm; she is open to either<br />
giving up the packages to the maintainers of the SBCL versions or to<br />
maintain the new, cross-platform versions herself if the SBCL-version<br />
maintainers don't want to).<br />
<br />
== Things you, the reader, can do ==<br />
<br />
* Maintain lisp packages following these guidelines<br />
* Update and fix problems with these guidelines<br />
* Keep up with what's changed here<br />
* Provide (polite) thoughts, feedback, and suggestions both on this document and to people's work.<br />
* Translate this page and future updates to this page.</div>Samwisehttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines&diff=54344Lisp package guidelines2008-11-30T05:10:57Z<p>Samwise: </p>
<hr />
<div>[[Category:Package development (English)]]<br />
[[Category:Guidelines (English)]]<br />
== Background ==<br />
<br />
At the moment, there are relatively few lisp packages available in the<br />
Arch repositories. This means that at some point or another, more will<br />
likely appear. It is useful, therefore, to figure out now, while there<br />
are few packages, how they should be packaged. Therefore, this page<br />
stands as a proposed packaging guideline for lisp packages. Keep in<br />
mind, however, that this is a work in progress; if you disagree with<br />
some of the ideas suggested here, feel free to edit the page and<br />
propose something better.<br />
<br />
== Directory Structure ==<br />
<br />
There is at least one package in the base repository (libgpg-error)<br />
that includes lisp files, which are placed in<br />
'''/usr/share/common-lisp/source/gpg-error'''. In keeping with this,<br />
other lisp packages should also place their files in<br />
'''/usr/share/common-lisp/source/'''. Each package should have its own<br />
directory, so as not to clutter up this base directory. The directory<br />
should be the name of the lisp package, not what it's called in the<br />
Arch repository (or AUR). This applies even to single-file packages.<br />
<br />
== ASDF ==<br />
<br />
Try to avoid the usage of ASDF-Install as a means of installing these<br />
system-wide packages.<br />
<br />
ASDF itself may be necessary or helpful as a means of compiling and/or<br />
loading packages. In that case, it is suggested that the directory<br />
used for the central registry (the location of all of the symlinks <br />
to *.asd) be '''/usr/share/common-lisp/systems/'''.<br />
<br />
However, I have observed problems with doing the compilation with asdf<br />
as a part of the package compilation process. However, it does work<br />
during an install, through use of a package.install file. Such a file<br />
might look like this:<br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/cl-ppcre/{*.fas,*.lisp}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Of course, for this example to work, there needs to be a symlink to<br />
package.asd in the asdf system directory. During package compilation,<br />
a stanza such as this will do the trick...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...where ''$_lispdir'' is '''${startdir}/pkg/usr/share/common-lisp'''.<br />
By linking to a relative, rather than an absolute, path, it's possible<br />
to guarantee that the link will not break post-install.<br />
<br />
== Lisp-specific packaging ==<br />
<br />
When possible, do not make packages specific to a single lisp<br />
implementation; try to be as cross-platform as the package itself will<br />
allow. If, however, the package is specifically designed for a single<br />
lisp implementation (i.e., the developers haven't gotten around to<br />
adding support for others yet, or the package's purpose is<br />
specifically to provide a capability that is built in to another lisp<br />
implementation), it is appropriate to make your Arch package<br />
lisp-specific.<br />
<br />
To avoid making packages implementation-specific, ideally all<br />
implementation packages (SBCL, cmucl, clisp) would be built with the<br />
PKGBUILD field '''common-lisp'''. However, that's not the case (and<br />
that would likely cause problems for people who prefer to have<br />
multiple lisps at their fingertips). In the meantime, you could (a)<br />
not make your package depend on *any* lisp and include a statement in<br />
the package.install file telling folks to make sure they have a lisp<br />
installed (not ideal), or (b) Take direction from the ''sbcl''<br />
PKGBUILD and include a conditional statement to figure out which lisp<br />
is needed (which is hackish and, again, far from ideal). Other ideas<br />
are welcome.<br />
<br />
Also note that if ASDF is needed to install/compile/load the package,<br />
things could potentially get awkward as far as dependencies go, since<br />
SBCL comes with asdf installed, clisp does not but there is an AUR<br />
package, and CMUCL may or may not have it (the author of this doc.<br />
knows next to nothing about CMUCL; sorry).<br />
<br />
People currently maintaining lisp-specific packages that don't need to<br />
be lisp-specific should consider doing at least one of the following:<br />
<br />
* Editing their PKGBUILD(s) to be cross-platform, provided someone else is not already maintaining the same package for a different lisp.<br />
<br />
* Offering to take over maintenance or help with maintenance of the same package for a different lisp, and then combining them into a single package.<br />
<br />
* Offering up their package to the maintainer of a different lisp's version of the same package, so as to allow that person to combine them into a single package.<br />
<br />
(Note that joyfulgirl, the author of this doc., currently maintains<br />
clisp versions of cl-ppcre and of stumpwm; she is open to either<br />
giving up the packages to the maintainers of the SBCL versions or to<br />
maintain the new, cross-platform versions herself if the SBCL-version<br />
maintainers don't want to).<br />
<br />
== Things you, the reader, can do ==<br />
<br />
* Maintain lisp packages following these guidelines<br />
* Update and fix problems with these guidelines<br />
* Keep up with what's changed here<br />
* Provide (polite) thoughts, feedback, and suggestions both on this document and to people's work.<br />
* Translate this page and future updates to this page.</div>Samwisehttps://wiki.archlinux.org/index.php?title=Shutdown_Pressing_Power_Button&diff=48925Shutdown Pressing Power Button2008-09-06T04:49:39Z<p>Samwise: Added link to more information about dbus and ksmserver</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Shutting system down by pressing the power button}}<br />
{{i18n_entry|Italiano|Arrestare il sistema premendo il pulsante di accensione}}<br />
{{i18n_entry|Русский|Выключение компьютера нажатием кнопки Power}}<br />
{{i18n_entry|Українська|Вимкнення_системи_кнопкою_Power}}<br />
{{i18n_entry|简体中文|使用电源开关关闭系统}}<br />
{{i18n_entry|Español|Apagar el sistema pulsando el botón de apagado}}<br />
{{i18n_links_end}}<br />
<br />
If you want to shutdown your system by simply pressing the power button, do the following:<br />
<br />
Install acpid package, if there is no hal in the DAEMONS array in rc.conf add acpid to it and create a file in ''/etc/acpi/events/'' named ''power'' with following content:<br />
<br />
<pre><br />
# /etc/acpi/events/power<br />
# This is called when the user presses the power button<br />
<br />
event=button/power (PWR.||PBTN)<br />
action=/sbin/poweroff<br />
</pre><br />
<br />
To be able to test it start the acpid daemon:<br />
/etc/rc.d/acpid start<br />
<br />
From now on pressing the power button (lightly, not for few seconds) should properly shutdown the system.<br />
{{i18n_entry|Español|Apagar el sistema pulsando el botón de apagado}}<br />
Note that if you have '''hibernate''' configured and working you may want to change the last line with:<br />
<pre><br />
action=/usr/sbin/hibernate<br />
</pre><br />
<br />
However, if you're using more sophisticated WM, you should use its own shutdown call, so it'd save its session etc. <br />
<br />
To accomplish it in '''KDE 3''', simply change the action to: <br />
''action=/opt/kde/bin/dcop --all-users --all-sessions ksmserver ksmserver logout 0 2 0''<br />
<br />
For '''KDE 4''', dcop is being phased out in favour of dbus, so as well as the above you could also use:<br />
''action=/usr/bin/qdbus org.kde.ksmserver /KSMServer logout 0 2 0''<br />
More information on using dbus is [http://samwiseandthestereotypical.blogspot.com/2008/09/using-dbus-and-ksmserver-to-logout-and.html here]<br />
Likewise for '''XFCE4.4''' change the action line to: <br />
''action=echo POWEROFF | /usr/lib/xfce4/xfsm-shutdown-helper''<br />
<br />
<br />
Note: For a more robust solution [If you are facing frequent WM crashes or working on a sacrificial PC for developing or testing your software...], you should take a look at "/usr/src/linux/Documentation/sysrq.txt", which is a kernel facility for yielding you [the user...] the CPU so that it could be used for any *rescue* work.</div>Samwisehttps://wiki.archlinux.org/index.php?title=Shutdown_Pressing_Power_Button&diff=47594Shutdown Pressing Power Button2008-08-15T10:54:38Z<p>Samwise: </p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Shutting system down by pressing the power button}}<br />
{{i18n_entry|Italiano|Arrestare il sistema premendo il pulsante di accensione}}<br />
{{i18n_entry|Русский|Выключение компьютера нажатием кнопки Power}}<br />
{{i18n_entry|Українська|Вимкнення_системи_кнопкою_Power}}<br />
{{i18n_entry|简体中文|使用电源开关关闭系统}}<br />
{{i18n_entry|Español|Apagar el sistema pulsando el botón de apagado}}<br />
{{i18n_links_end}}<br />
<br />
If you want to shutdown your system by simply pressing the power button, do the following:<br />
<br />
Install acpid package, add acpid to the DAEMONS array in rc.conf and create a file in ''/etc/acpi/events/'' named ''power'' with following content:<br />
<br />
<pre><br />
# /etc/acpi/events/power<br />
# This is called when the user presses the power button<br />
<br />
event=button/power (PWR.||PBTN)<br />
action=/sbin/poweroff<br />
</pre><br />
<br />
To be able to test it start the acpid daemon:<br />
/etc/rc.d/acpid start<br />
<br />
From now on pressing the power button (lightly, not for few seconds) should properly shutdown the system.<br />
{{i18n_entry|Español|Apagar el sistema pulsando el botón de apagado}}<br />
Note that if you have '''hibernate''' configured and working you may want to change the last line with:<br />
<pre><br />
action=/usr/sbin/hibernate<br />
</pre><br />
<br />
However, if you're using more sophisticated WM, you should use its own shutdown call, so it'd save its session etc. <br />
<br />
To accomplish it in '''KDE 3''', simply change the action to: <br />
''action=/opt/kde/bin/dcop --all-users --all-sessions ksmserver ksmserver logout 0 2 0''<br />
<br />
For '''KDE 4''', dcop is being phased out in favour of dbus, so as well as the above you could also use:<br />
''action=/usr/bin/qdbus org.kde.ksmserver /KSMServer logout 0 2 0''<br />
<br />
Likewise for '''XFCE4.4''' change the action line to: <br />
''action=echo POWEROFF | /usr/lib/xfce4/xfsm-shutdown-helper''<br />
<br />
<br />
Note: For a more robust solution [If you are facing frequent WM crashes or working on a sacrificial PC for developing or testing your software...], you should take a look at "/usr/src/linux/Documentation/sysrq.txt", which is a kernel facility for yielding you [the user...] the CPU so that it could be used for any *rescue* work.</div>Samwisehttps://wiki.archlinux.org/index.php?title=Shutdown_Pressing_Power_Button&diff=47592Shutdown Pressing Power Button2008-08-15T10:10:54Z<p>Samwise: Added alternative kde logout method using dbus instead of dcop</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Shutting system down by pressing the power button}}<br />
{{i18n_entry|Italiano|Arrestare il sistema premendo il pulsante di accensione}}<br />
{{i18n_entry|Русский|Выключение компьютера нажатием кнопки Power}}<br />
{{i18n_entry|Українська|Вимкнення_системи_кнопкою_Power}}<br />
{{i18n_entry|简体中文|使用电源开关关闭系统}}<br />
{{i18n_entry|Español|Apagar el sistema pulsando el botón de apagado}}<br />
{{i18n_links_end}}<br />
<br />
If you want to shutdown your system by simply pressing the power button, do the following:<br />
<br />
Install acpid package, add acpid to the DAEMONS array in rc.conf and create a file in ''/etc/acpi/events/'' named ''power'' with following content:<br />
<br />
<pre><br />
# /etc/acpi/events/power<br />
# This is called when the user presses the power button<br />
<br />
event=button/power (PWR.||PBTN)<br />
action=/sbin/poweroff<br />
</pre><br />
<br />
To be able to test it start the acpid daemon:<br />
/etc/rc.d/acpid start<br />
<br />
From now on pressing the power button (lightly, not for few seconds) should properly shutdown the system.<br />
{{i18n_entry|Español|Apagar el sistema pulsando el botón de apagado}}<br />
Note that if you have '''hibernate''' configured and working you may want to change the last line with:<br />
<pre><br />
action=/usr/sbin/hibernate<br />
</pre><br />
<br />
However, if you're using more sophisticated WM, you should use its own shutdown call, so it'd save its session etc. <br />
<br />
To accomplish it in '''KDE 3''', simply change the action to: <br />
''action=/opt/kde/bin/dcop --all-users --all-sessions ksmserver ksmserver logout 0 2 0''<br />
<br />
For '''KDE 4''', dcop is being phased out in favour of dbus, so as well as the above you could also use:<br />
''action=/usr/bin/qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.logout 0 2 0''<br />
<br />
Likewise for '''XFCE4.4''' change the action line to: <br />
''action=echo POWEROFF | /usr/lib/xfce4/xfsm-shutdown-helper''<br />
<br />
<br />
Note: For a more robust solution [If you are facing frequent WM crashes or working on a sacrificial PC for developing or testing your software...], you should take a look at "/usr/src/linux/Documentation/sysrq.txt", which is a kernel facility for yielding you [the user...] the CPU so that it could be used for any *rescue* work.</div>Samwisehttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=46418Disable clearing of boot messages2008-07-25T13:04:54Z<p>Samwise: Explained how to enter escape character in emacs as well as vim.</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Q: How can I turn OFF clearing the screen after system has booted so I can see the messages that are printed out during system startup?==<br />
<br />
'''A: '''Delete the first character of '''/etc/issue''' It looks like: '''^[c'''<br />
<br />
In some cases you'll need to delete the whole first line of this file, as there is more than one instructions, i.e. one clears the screen and the other one places the cursor at the top.<br />
<br />
==Q: How do I put it back again?==<br />
<br />
<b>A: </b>You can't just type the characters back as you have to put a literal escape character. This is editor dependent. In vim:<br />
<br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In emacs:<br />
<br />
C-q ESC (to insert literal escape)<br />
<br />
But if you want to keep the screen clear after logging out on a virtual terminal, without clearing after system has booted, just do:<br />
<br />
<pre><br />
echo clear >> ~/.bash_logout<br />
</pre></div>Samwisehttps://wiki.archlinux.org/index.php?title=Keyboard_input&diff=46405Keyboard input2008-07-25T06:19:21Z<p>Samwise: /* In KDE */</p>
<hr />
<div>[[Category:Input devices (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=See if your kernel can see the scancode=<br />
The first thing you should do is to see if the key produces a scancode [http://en.wikipedia.org/wiki/Scancode 1] as that will mean you won't need to bother with working or non-working third-party apps. To see if the kernel recognizes the extra key, press the non-standard key(doesn't matter wether you are in xorg or framebuffer or whatever) and see if a msg similar to:<br />
<br />
atkbd.c: Unknown key pressed (translated set 2, code 0x9e on isa0060/serio0).<br />
atkbd.c: Use 'setkeycodes e01e <keycode>' to make it known.<br />
<br />
appears at the bottom after typing:<br />
<br />
dmesg<br />
<br />
If it does then all you have to do is to find a spare keycode(as root):<br />
<br />
getkeycodes<br />
<br />
and bind the scancode to the free keycode:<br />
<br />
setkeycodes e01e 129<br />
<br />
for example. I think X recognizes scancodes up to 229(atleast that's the highest number gnome's keymapping utility wants to work with for me...)<br />
<br />
You can see if xorg now recognizes the key by launching 'xev' and watching for output when you press the key.<br />
<br />
All keyboard program launching programs will recognize the key and will allow you to bind the key to do some action. Programs like 'xbindkeys' or gnome's in the entry below here...<br />
<br />
To keep the key over reboots you have to put the cmd's in some startup file like rc.local(all users) or .bashrc(user specific).<br />
<br />
setkeycodes 0x71 112 &<br />
<br />
More enlightening info can be found on these pages: [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html HAL Keymap Quirks] There are also another arch wikipage here: [http://wiki.archlinux.org/index.php/Hotkeys Hotkeys] but i don't think there is a point to trying showkey as it didn't work for me and the HAL guide only mentions the dmesg output.<br />
<br />
=In Gnome=<br />
<br />
Users of the Gnome Desktop Environment may find their extra keys are recognised by Gnome's keybindings tool. This is part of the Control-Center package, and can be accessed via System->Preferences->Keyboard Shortcuts, or by running gnome-keybinding-properties. Gnome has a handy on-screen display of volume levels if your multimedia keys are configured this way.<br />
However, many extra keys will not be configurable in this manner.<br />
<br />
=In KDE=<br />
<br />
'''Method 1'''<br />
<br />
Info extracted from: [http://www.kde.me.uk/index.php?page=kmilo KMiLo info page]<br />
<br />
(C&P) In the KDE CVS version there is also a generic plugin for all kayboards with volume up/down keys acknowledged by X/KDE by default. Just start the X program xev and press your laptop's vol up/down keys to check. If it prints out some meaningful information, you can use it to setup KDE to take care of these and connect them to RaiseVolume, etc.<br />
<br />
If it does not work out of the box, your X keybindings have to set up. Usually, you do this in ~/.Xmodmap<br />
<br />
Example:<br />
<br />
keycode 129 = XF86AudioMedia<br />
keycode 144 = XF86AudioPrev<br />
keycode 153 = XF86AudioNext<br />
keycode 160 = XF86AudioMute<br />
keycode 161 = XF86Calculator<br />
keycode 162 = XF86AudioPause<br />
keycode 164 = XF86AudioStop<br />
keycode 174 = XF86AudioLowerVolume<br />
keycode 176 = XF86AudioRaiseVolume<br />
keycode 223 = XF86Standby<br />
<br />
This assigns e.g. keycode 160 to XF86AudioMute which triggers mute in the kmilo generic plugin. How to find out? start xev, move your mouse into the window and press the keys. .Xmodmap is read every time you start X. Use "xmodmap .Xmodmap" to test your configuration file.<br />
<br />
'''The available names for the keys ( e.g. XF86AudioMute ) can be found in the file /usr/share/X11/XKeysymDB'''<br />
<br />
<br />
'''Method 2 - The practical way'''<br />
<br />
As described above in konsole type '''''xev''''' to get the keycodes. Write them down. The create a file in /etc/X11/ named ''Xmodmap''. I give as an example my Xmodmap file (you can have more or less and different keycodes and/or buttons to you keyboard):<br />
<br />
keycode 176 = XF86AudioRaiseVolume<br />
keycode 174 = XF86AudioLowerVolume<br />
keycode 160 = XF86AudioMute<br />
keycode 236 = XF86Mail<br />
keycode 178 = XF86WWW<br />
keycode 135 = XF86MyComputer<br />
keycode 140 = XF86Launch1<br />
keycode 248 = XF86Launch2<br />
keycode 214 = XF86Launch3<br />
keycode 146 = XF86AudioMedia<br />
keycode 201 = XF86Launch4<br />
keycode 222 = XF86PowerDown<br />
<br />
Create a new bash script in /usr/local/bin/ named ''hotkeys.sh'' and paste the following:<br />
<br />
#!/bin/bash<br />
xmodmap /etc/X11/Xmodmap<br />
<br />
Make it executable:<br />
<br />
chmod +x /usr/local/bin/hotkeys.sh<br />
<br />
Now you can make a shortcut and place it anywhere. I have made one in the kde menu and in '''~/.kde/Autostart''' folder. In the kde menu editor you can bind these keys to any program you wish. Alternatively you can make manually a shortcut for /usr/local/bin/hotkeys.sh. In konsole type:<br />
<br />
nano ~/.kde/Autostart/hotkeys.desktop<br />
<br />
And paste the following:<br />
<br />
[Desktop Entry]<br />
Comment=<br />
Exec='/usr/local/bin/hotkeys.sh'<br />
GenericName=<br />
Icon=keyboard<br />
Name=hotkeys<br />
Path=<br />
StartupNotify=false<br />
Terminal=0<br />
TerminalOptions=<br />
Type=Application<br />
X-KDE-SubstituteUID=false<br />
X-KDE-Username=<br />
<br />
Now, if you want to bind a key with a program(for example: XF86WWW with Firefox), you can do it through the Control Center. Go to Control Center -> Regional & Accessibility -> Keyboard Shortcuts -> Command Shortcuts, choose the program and press the key.<br />
<br />
An alternative to creating a hotkeys.sh script is to put the line<br />
<br />
xmodmap /etc/X11/Xmodmap<br />
<br />
in your ~/.xinitrc file. I prefer to put keybindings in my home directory in ~/.Xmodmap, so I change this line to <br />
<br />
xmodmap $HOME/.Xmodmap<br />
<br />
=HAL=<br />
HAL(or hal-info) is now supposed to replace the functionality of lineakd, keytouch and similar programs, so you might want to go that route for the future.<br />
<br />
[http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html HAL information]<br />
<br />
=The Keytouch Program=<br />
<br />
KeyTouch is a program which allows you to easily configure the extra function keys of your keyboard. This means that you can define, for every individual function key, what to do if it is pressed.<br />
The wiki will try to explain how keytouch is used in Arch linux. For further documentation, please have a look at the keytouch documentation at http://keytouch.sourceforge.net/doc.html<br />
<br />
==Install==<br />
* Install keytouch package from the community repo:<br />
# pacman -S keytouch<br />
===Alternative way (build it yourself)===<br />
* Download the keytouch PKGBUILD from [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/system/keytouch/?cvsroot=AUR&only_with_tag=CURRENT here.] Don't forget the files 'keytouch.install', 'keytouch.daemon', and 'keytouch.desktop' as well - they are used by the PKGBUILD in the 'source' list, and may be accessible from the same url given. Put these 3 files and the PKGBUILD in the same directory.<br />
<br />
* Run makepkg<br />
<pre>makepkg</pre><br />
<br />
* Install Package Using Pacman<br />
<pre>pacman -U keytouch-$VERSION.pkg.tar.gz</pre><br />
<br />
==Make Keyboard File==<br />
''Note: You need a keyboard file for your keyboard model. The package build includes some of them. You can also check http://keytouch.sourceforge.net/dl-keyboards.html''<br />
<br />
If your model is not included in the keytouch package you will need to create one for yourself:<br />
* Install keytouch-editor:<br />
# pacman -S keytouch-editor<br />
* Make sure you have evdev loaded (you should not need to do this if you using the stock kernel)<br />
# modprobe evdev<br />
* We are going to need to make a keyboard file which is very simple. You need to find out which input device is your keyboard first:<br />
# ls /dev/input/<br />
Every event device (like a keyboard or a mouse) is related to one of these files.<br />
To find out which file belongs to your keyboard, run:<br />
# keytouch-editor /dev/input/eventX mykeyboardconfig<br />
Replace the X by a number. KeyTouch editor will first show some information<br />
about the device, including its name (”Input device name”) that can tell you<br />
if you have chosen the correct event device. KeyTouch editor asks you to press<br />
one of the extra function keys. If the program continues after pressing the<br />
extra function key, you have chosen the right event device. If not terminate the<br />
program by pressing Ctrl+C and try another event device.<br />
Note that when your keyboard is connected via USB there are two event<br />
devices: /dev/input/eventA (where A is replaced by a number) for all ”normal”<br />
keys and /dev/input/eventB (where B = A+1) for the extra function keys.<br />
<br />
* After you have found the correct device, follow the steps. keytouch-editor asks your name and the name of the manufacturer and model of your keyboard.<br />
<br />
* Now it is time to tell keytouch-editor about your extra function keys. You will see the following message:<br />
Press an extra function key or press enter to finish...<br />
If your keyboard is connected via USB or you started keyTouch editor with the<br />
”–acpi” option, you will not see this message, but instead:<br />
Press return to a new key or enter F followed by return to finish...<br />
* First you will have to press the extra function key so that the program knows which key you mean. It is important that you do not press any other key than the extra function key. After pressing the key you will be asked to enter the keys name, keycode and default action.<br />
* Key name<br />
Choose an appropriate name for the key. If there is for example a text label on<br />
the key, use the label as the key’s name.<br />
* Keycode<br />
Use one of the keycodes listed below. It actually doesn’t matter which keycode<br />
you choose. However it is recommended that you choose a keycode that matches<br />
the best the function of the key. A keycode may only be used once in a keyboard<br />
file.<br />
<pre>AGAIN EJECTCLOSECD MAIL REFRESH<br />
ALTERASE EMAIL MEDIA REWIND<br />
BACK EXIT MENU RIGHTMETA<br />
BASSBOOST FASTFORWARD MOVE SCROLLDOWN<br />
BOOKMARKS FILE MSDOS SCROLLUP<br />
BRIGHTNESSDOWN FINANCE MUTE SEARCH<br />
BRIGHTNESSUP FIND NEXTSONG SENDFILE<br />
CALC FORWARD OPEN SETUP<br />
CAMERA FRONT PASTE SHOP<br />
CANCEL HANGUEL PAUSE SLEEP<br />
CHAT HANJA PAUSECD SOUND<br />
CLOSE HELP PHONE SPORT<br />
CLOSECD HOMEPAGE PLAY STOP<br />
COFFEE HP PLAYCD STOPCD<br />
COMPOSE ISO PLAYPAUSE SUSPEND<br />
COMPUTER KBDILLUMDOWN POWER SWITCHVIDEOMODE<br />
CONFIG KBDILLUMTOGGLE PREVIOUSSONG UNDO<br />
CONNECT KBDILLUMUP PRINT VOLUMEDOWN<br />
COPY KPCOMMA PROG1 VOLUMEUP<br />
CUT KPEQUAL PROG2 WAKEUP<br />
CYCLEWINDOWS KPLEFTPAREN PROG3 WWW<br />
DELETEFILE KPPLUSMINUS PROG4 XFER<br />
DIRECTION KPRIGHTPAREN PROPS YEN<br />
EDIT LEFTMETA QUESTION<br />
EJECTCD MACRO RECORD</pre><br />
<br />
You can find the correct keycodes from here: http://keytouch.sourceforge.net/keytouch_editor/node7.html<br />
<br />
* Default action<br />
It is important to realize that the default action for a key, is not the action you want to use for this key, but one that corresponds to the function of the key.<br />
The default action can be a program or a plugin. If it is a program, just fill in the name of the program. If it is a plugin type ”plugin” (without the quotes) instead. Then fill in the name of the plugin. To get a list of all available plugins, run keyTouch and go to the ”Preferences” part. Select the plugin and click the ”Information...” button to get a list of the functions of the selected plugin. After entering the plugins name in keytouch-editor, fill in the function<br />
name. Note that the name and function you fill in are case sensitive.<br />
<br />
* When you entered the information, the program asks again to press an extra function key. If there are no more extra function keys, just press enter to write the output file and terminate the program.<br />
<br />
===Share it===<br />
After you made the file and tested it, it would be a good idea to send it to the author of keytouch so he can include it in the next release. This helps future users of keytouch who have the same keyboard as you do.<br />
marvinr users.sourceforge.net<br />
(You know there's a missing @ because of spam bots ;))<br />
<br />
==Configure keytouch==<br />
* We now need to run keytouch<br />
<pre>keytouch</pre><br />
<br />
* What to do...<br />
# When you see the list of keyboards select import and find where you put the keyboard config file you just made.<br />
# Now you should see your keyboard module and manufacturer. Select it and click ok.<br />
# Now you get to the keytouch configuration theme. I think this is pretty self explanatory.<br />
<br />
==Starting the keytouch daemon==<br />
* You should start the keytouch daemon at boot time (add <code>keytouch</code> to the daemons array in <code>/etc/rc.conf</code>)<br />
* You have to load keytouchd on your session startup. There is a script /etc/X11/Xsession which runs all daemons located in /etc/X11/Xsession.d/ including the keytouchd.<br />
** You can add /etc/X11/Xsession into your ~/.xinitrc if you log in from console<br />
** If you, however, use KDM as your login manager .xinitrc will not be parsed. You can add <code>/etc/X11/Xsession</code> to your session list of your Desktop Environment (Gnome, Kde, Xfce-svn, among others).<br />
<br />
==Troubleshooting==<br />
* <b>When I change the volume with the special keys, the OSD looks ugly. What's wrong?:</b><br />
<br />
Maybe you have started the <code>/etc/X11/Xsession</code> script as root. This is what happens when you place "<code>/etc/X11/Xsession</code>" on a script like <code>/opt/kde/share/config/kdm/Xstartup</code>.<br />
The only thing that <code>/etc/X11/Xsession</code> script does, is to look on <code>/etc/X11/Xsession.d/</code> and execute every script that is there. Once you have installed <code>keytouch</code>, two scripts are created there:<br />
<pre>$ pwd<br />
/etc/X11/Xsession.d<br />
$ ls<br />
91keytouch-acpid_launch 92keytouchd_launch<br />
</pre><br />
If them aren't executed, there is no <code>keytouchd</code> for you. But if you execute them as root (e.g. in a KDM startup script) they will look ugly and that isn't good for most people. Just run them as yourself (e.g. creating a symbolic link of <code>/etc/X11/Xsession</code> in <code>~/.kde/Autostart</code>).<br />
<br />
* <b>My multimedia keys (Play/Pause/Previos/Next...) doesn't work at all:</b><br />
The problem is probably the same as above. If you run <code>keytouchd</code> as root, the programs you run with the multimedia keys are expected to run as root, they just won't work.<br />
<br />
* <b>I've just created a brand new keyboard file for my own model (using <code>keytouch-editor</code>) but when I select it in <code>keytouch</code>, it says that my keyboard file doesn't exist. I know that is there!:</b><br />
<br />
Actually, the error isn't that the file doesn't exist: It only has a bad filename.<br />
When you make your own keyboard file, you have to make sure that your filename has <i>exactly</i> this format:<br />
<pre>Model.Manufacturer</pre><br />
For example:<br />
<pre>Satellite-L25-SP141.Toshiba</pre><br />
<br />
That should do the trick.<br />
<br />
=The Lineak Program=<br />
<br />
http://lineak.sourceforge.net/<br />
<br />
Have you ever wanted to get your multimedia keys to work under linux? If so; then Lineak is the perfect program for you because it does exactly this, Plus more (if needed). Lineak is a utility designed to enable the use and configuration of those special keys on Internet, Easy Access and Multimedia keyboards in Linux. It consists of three programs: '''lineakd''': this is the daemon that listens for incoming key and mouse events. '''lineakconfig''': this is the GTK+ GUI, which provides easier configuration '''Klineakconfig''': this is the KDE GUI which allows you to define keyboards, and configuration mappings for easier configuration. If your keyboard is not directly supported by lineakd, klineakconfig provides an easy to use graphic interface to both getting your keyboard working, and submitting your keyboard for inclusion into lineakd.<br />
<br />
Personally, In this tutorial I am not going to be using any of the GUI tools that I meantioned. I much rather do everything by hand, besides, you'll learn more this way. I will however provide more information on these tools at the end of this Wiki if you're interesting in GUI tools.<br />
<br />
If you do have any problems with this howto, please e-mail me at. [mailto:twiistedkaos@gmail.com twiistedkaos@gmail.com]. I'd much appreciate it, it'll help me enhance my howto writing skills :).<br />
<br />
== '''Check to see if Lineak supports your keyboard''' ==<br />
Does Lineak support my keyboard? Heck if I know, does it? There is a very easy way to check though, and I'll tell you exactly how! Simply type this into your terminal shell:<br />
xev<br />
You should get a window that pops up along with some terminal output. Now press one of your multimedia keys, any... It doesn't really matter at this point. You should get an output like the following:<br />
KeyPress event, serial 32, synthetic NO, window 0x2600001,<br />
root 0xea, subw 0x0, time 24644050, (143,-13), root: (548,770),<br />
state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,<br />
XLookupString gives 0 bytes:<br />
XmbLookupString gives 0 bytes:<br />
<br />
XFilterEvent returns: False<br />
KeyRelease event, serial 32, synthetic NO, window 0x2600001,<br />
root 0xea, subw 0x0, time 24644215, (143,-13), root: (548,770),<br />
state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,<br />
XLookupString gives 0 bytes:<br />
If you get something around these lines, then your keyboard will be supported, if you don't get anything make sure the "Event Tester" window is the active one when you press the key and then try again. If you still don't get something like what I pasted above then sadly, your keyboard is one of the few that aren't supported and won't ever be supported through Lineak, even on Windows these rare keyboards require "special" drivers.<br />
<br />
== '''Software Installation''' ==<br />
!!These instructions are out of date!!<br />
lineakd & lineak_defaultplugin are no longer in the repo's, please acquire and build them from AUR.<br />
<br />
Open your terminal shell and type in the following:<br />
pacman -Sy lineakd lineak_defaultplugin<br />
<br />
If you want OSD (On Screen Display) then you should also install this plugin:<br />
pacman -Sy lineak_xosdplugin<br />
and when ever you press a key you'll get a nice little text displayed on your screen telling you what key you just pressed. But in my case I found this sort of annoying and skipped it :P.<br />
<br />
== '''Configuring Your Specific Keyboard''' ==<br />
Lineak does support many keyboards so you may want to check and see if your keybaord is supported by Lineak. But, for educational purposes. I am going to explain to you how to write your own keyboard layout from scratch. So even if your keyboard is / or isn't supported this method will always work.<br />
<br />
Once again run xev:<br />
xev<br />
Make sure the "Event Tester" window is the active one and start pressing your multimedia keys one by one and write down somewhere what the keycode is. For example:<br />
KeyPress event, serial 32, synthetic NO, window 0x3a00001,<br />
root 0xea, subw 0x0, time 27586934, (-4,185), root: (0,253),<br />
state 0x0, '''keycode 234''' (keysym 0x0, NoSymbol), same_screen YES,<br />
XLookupString gives 0 bytes:<br />
XmbLookupString gives 0 bytes:<br />
XFilterEvent returns: False<br />
The keycode for that key is 234. So I would write down something like: GoBack - 234. Get it? Now do that for all your multimedia keys you plan to setup. Here's the list I have:<br />
GoBack = 234<br />
Play = 162<br />
Favorites = 230<br />
Mail = 236<br />
SpeakerOff = 160<br />
Home = 178<br />
Next = 233<br />
Search = 229<br />
Repeat = 231<br />
Cancel = 232<br />
ScreenShot = 111<br />
<br />
Now open up /etc/lineakkb.def in any editor you feel like. And create a section like this:<br />
[HP]<br />
brandname = "HP"<br />
modelname = "Custom"<br />
[KEYS]<br />
GoBack = 234<br />
Play = 162<br />
Favorites = 230<br />
Mail = 236<br />
SpeakerOff = 160<br />
Home = 178<br />
Next = 233<br />
Search = 229<br />
Repeat = 231<br />
Cancel = 232<br />
ScreenShot = 111<br />
[END KEYS]<br />
[END HP]<br />
Now you have your basic configuration done!! Cool huh? Now lets test and make sure that you have it configured correctly. Type this into your terminal shell:<br />
lineakd -c HP<br />
then type:<br />
lineakd -v<br />
Press each and every one of your keys and make sure they are outputing the correct settings. Then press '''Ctrl+C''' if everything is correct and move onto the next step.<br />
<br />
Type in the following in your terminal shell<br />
mkdir ~/.lineak<br />
then type:<br />
nano ~/.lineak/lineakd.conf<br />
just replace nano with your favorite editor. In that file put something similar to the folllowing:<br />
Cancel = xmms --stop (or "[http://wiki.archlinux.org/index.php/Extra_Keyboard_Keys#ReMoot| remoot]stop" to make it work with most apps<br />
Favorites = firefox<br />
GoBack = xmms --rew <br />
Next = xmms --fwd<br />
Home = nautilus --no-desktop /home/josh<br />
Mail = firefox http://www.gmail.com/<br />
Play = xmms --play-pause <br />
Repeat = <br />
Search = <br />
Sleep = <br />
SpeakerOff = <br />
ScreenShot = sh $HOME/screen.sh<br />
Save that file and now in your terminal type the following:<br />
lineakd &<br />
and you will now have your multimedia keys setup correctly. Now just add the command '''lineakd &''' to your session startup and walla. You now have your very own multimedia keyboard working on linux.<br />
<br />
=ReMoot=<br />
[http://www.kde-apps.org/content/show.php/ReMoot?content=63140 ReMoot] is not a key mapper but it is very handy to use with a key mapper like Lineak or Keytouch. Usually its only possible to map an action to ONE application. By mapping your multimedia keyboard to ReMoot you can control most (18) multimedia applications with the same keys (play/pause buttons etc.).<br />
<br />
remoot is available in [http://aur.archlinux.org/packages.php?do_Details=1&ID=14980&O=0&L=0&C=0&K=remoot&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd AUR].<br />
<br />
=Share it=<br />
After you have made your new /etc/lineakkb.def, please send it to the developers of lineak by emailing the file (or pasting it into the body of your email, this is usually preferred with mailing lists) to<br />
lineak-devel lists.sourceforge.net<br />
Again, the @ is missing for the benefit of spam bots.<br />
Sharing the file allows other users of lineak who have the same keyboard as you to benefit from your efforts in getting lineak to work.<br />
<br />
= Disabling auto-repeat =<br />
(Almost C&P from [http://gentoo-wiki.com/HOWTO_Use_Multimedia_Keys#Disabling_auto-repeat Gentoo Wiki])<br />
<br />
You may find that your keyboard has autorepeat enabled for the multimedia keys, which has the undesirable effect of the "next track" button sometimes skipping ahead by too many songs or the "play/pause" button pausing and then resuming immediately, if you accidentally hold the button down for a fraction too long.<br />
<br />
Rather than altering your whole keyboard's auto-repeat timing to fix this, you can disable auto-repeat completely for specific keys (or enable it, if you have buttons to control the volume and you'd like to be able to hold these down instead of pressing them repeatedly to adjust the volume.) This can be done by running the xset command at startup (a good place is /etc/X11/xinit/xinitrc):<br />
<br />
# Disable autorepeat for multimedia keys (except the volume controls)<br />
xset -r 162 -r 164 -r 160 -r 144 -r 153<br />
<br />
# The keycodes are the same ones supplied to xmodmap, or detected by xev<br />
<br />
# Use "r" instead of "-r" to enable autorepeat instead if<br />
# the keyboard doesn't natively repeat the key.<br />
<br />
= '''GUI Tools''' =<br />
'''LineakConfig''' - http://prdownloads.sourceforge.net/lineak/lineakconfig-0.3.2.tar.gz - GTK+ GUI<br />
<br />
'''klineakconfig''' - http://prdownloads.sourceforge.net/lineak/klineakconfig-0.5.1.tar.gz - QT / KDE GUI<br />
<br />
These are pretty straight forward GUI tools and you should have no problem in using these tools.<br />
<br />
=External Links=<br />
[http://gentoo-wiki.com/HOWTO_Use_Multimedia_Keys Multimedia Keys in Gentoo Wiki (very complete and useful)]</div>Samwise