[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering ACPI events. These events are triggered by certain actions, such as:

+

[[zh-CN:Acpid]]

−

* Pressing the Power button

+

−

* Pressing the Sleep/Suspend button

+

[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:

+

* Pressing special keys, including the Power/Sleep/Suspend button

* Closing a notebook lid

* Closing a notebook lid

* (Un)Plugging an AC power adapter from a notebook

* (Un)Plugging an AC power adapter from a notebook

+

* (Un)Plugging phone jack etc.

+

acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.

acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.

−

{{Warning|Please note that [[Desktop Environment|desktop environments]] such as [[GNOME]] tend to have their own means of handling ACPI events, independent of acpid. Running both systems at the same time may lead to unexpected behaviour such as suspending and shutting down at the same time, when the power button is pressed or suspending two times in a row after one sleep button press. You should be aware of this and disable duplicate event handlers in one or the other configuration system, when using acpid and such desktop environments simultaneously.}}

+

{{Note|

+

* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.

+

* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}

== Installation ==

== Installation ==

Line 16:

Line 20:

[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].

[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].

−

Edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]] to have it start on boot.

+

To have it start on boot :

+

* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;

+

* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].

== Configuration ==

== Configuration ==

Line 104:

Line 110:

# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.

# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.

−

xs=$(ps up $(pidof xscreensaver) | awk '/xscreensaver/ {print $1}')

+

xs=$(ps -C xscreensaver -o user=)

if test $xs; then su $xs -c "xscreensaver-command -lock"; fi

if test $xs; then su $xs -c "xscreensaver-command -lock"; fi

;;

;;

Line 143:

Line 149:

=== Enabling volume control ===

=== Enabling volume control ===

−

Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a pair of scripts to control the volume (assuming an [[ALSA]] sound card):

+

Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a script to control the volume (assuming an [[ALSA]] sound card):

+

+

{{hc|/etc/acpi/handlers/vol|<nowiki>

+

#!/bin/sh

+

step=5

−

{{hc|/etc/acpi/actions/volume_up.sh|<nowiki>

+

case $1 in

−

#!/bin/bash

+

-) amixer set Master $step-;;

−

/usr/bin/amixer set Master 5%+

+

+) amixer set Master $step+;;

+

esac

</nowiki>}}

</nowiki>}}

−

{{hc|/etc/acpi/actions/volume_down.sh|<nowiki>

+

and connect these to new acpi events:

−

#!/bin/bash

+

−

/usr/bin/amixer set Master 5%-

+

{{hc|/etc/acpi/events/vol_d|<nowiki>

+

event=button/volumedown

+

action=/etc/acpi/handlers/vol -

+

</nowiki>}}

+

{{hc|/etc/acpi/events/vol_u|<nowiki>

+

event=button/volumeup

+

action=/etc/acpi/handlers/vol +

</nowiki>}}

</nowiki>}}

−

and connect these to new acpi events:

+

as well as another event to toggle the mute setting:

+

+

{{hc|/etc/acpi/events/mute|<nowiki>

+

event=button/mute

+

action=/usr/bin/amixer set Master toggle

+

</nowiki>}}

+

+

=== Enabling backlight control ===

+

+

Similar to volume control, acpid also enables you to control screen backlight. To achieve this you write some handler, like this:

+

+

{{hc|/etc/acpi/handlers/bl|<nowiki>

+

#!/bin/sh

+

bl_dev=/sys/class/backlight/acpi_video0

+

step=1

+

+

case $1 in

+

-) echo $((`cat $bl_dev/brightness` - $step)) >$bl_dev/brightness;;

+

+) echo $((`cat $bl_dev/brightness` + $step)) >$bl_dev/brightness;;

+

esac

+

</nowiki>}}

+

+

and again, connect keys to ACPI events:

−

{{hc|/etc/acpi/events/volume_up|<nowiki>

+

{{hc|/etc/acpi/events/bl_d|<nowiki>

−

event=button[ /]volumeup

+

event=video/brightnessdown

−

action=/etc/acpi/actions/volume_up.sh

+

action=/etc/acpi/handlers/bl -

</nowiki>}}

</nowiki>}}

+

{{hc|/etc/acpi/events/bl_u|<nowiki>

+

event=video/brightnessup

+

action=/etc/acpi/handlers/bl +

+

</nowiki>}}

+

+

=== Enabling Wi-fi toggle ===

+

+

You can also create a simple wireless-power switch by pressing the WLAN button. Example of event:

−

{{hc|/etc/acpi/events/volume_down|<nowiki>

+

{{hc|/etc/acpi/events/wlan|<nowiki>

−

event=button[ /]volumedown

+

event=button/wlan

−

action=/etc/acpi/actions/volume_down.sh

+

action=/etc/acpi/handlers/wlan

</nowiki>}}

</nowiki>}}

−

as well as another event to toggle the mute setting:

+

and its' handler:

+

+

{{hc|/etc/acpi/handlers/wlan|<nowiki>

+

#!/bin/sh

+

rf=/sys/class/rfkill/rfkill0

−

{{hc|/etc/acpi/events/volume_mute|<nowiki>

+

case `cat $rf/state` in

−

event=button[ /]volumemute

+

0) echo 1 >$rf/state && systemctl start net-auto-wireless;;

−

action=/usr/bin/amixer set Master toggle

+

1) systemctl stop net-auto-wireless && echo 0 >$rf/state;;

+

esac

</nowiki>}}

</nowiki>}}

Line 220:

Line 272:

esac

esac

;;

;;

+

+

+

On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].

==See also==

==See also==

Revision as of 00:08, 19 February 2013

acpid is a flexible and extensible daemon for delivering ACPI events. It listens on /proc/acpi/event and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:

Pressing special keys, including the Power/Sleep/Suspend button

Closing a notebook lid

(Un)Plugging an AC power adapter from a notebook

(Un)Plugging phone jack etc.

acpid can be used by itself, or combined with a more robust system such as pm-utils and cpufrequtils to provide a more complete power management solution.

Note:

desktop environments, such as GNOME, systemd login manager and some extra key handling daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.

Since by default the script provided by acpid, /etc/acpi/handler.sh, will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).

Configuration

acpid comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in /etc/acpi/handler.sh, which is executed after any ACPI events are detected (as determined by /etc/acpi/events/anything).

The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command echo -n mem >/sys/power/state which should place the computer into a sleep (suspend) state:

The output of acpi_listen is sent to /etc/acpi/handler.sh as $1, $2 , $3 & $4 parameters.
Example:

$1 power/button
$2 PBTN
$3 00000000
$4 00000b31

As you might have noticed, the Sleep button in the sample output is actually recognized as SBTN, rather than the SLPB label specified in the default /etc/acpi/handler.sh. In order for Sleep function to work properly on this machine, we would need to replace SLPB) with SBTN).

Using this information as a base, you can easily customize the /etc/acpi/handler.sh file to execute a variety of commands depending on which event is triggered. See the Tips & Tricks section below for other commonly used commands.

Alternative configuration

By default, all ACPI events are passed through the /etc/acpi/handler.sh script. This is due to the ruleset outlined in /etc/acpi/events/anything:

While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:

Using this method, it is easy to create any number of individual event/action scripts.

Tips and tricks

Extending acpid with pm-utils

Although acpid can provide basic suspend2ram out-of-the-box, a more robust system may be desired. pm-utils provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, pm-suspend and pm-hibernate, both of which can be inserted as events into acpid. For more information, check the pm-utils wiki.

Example Events

The following are examples of events that can be used in the /etc/acpi/handler.sh script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by acpi_listen.

To lock the screen with xscreensaver when closing the laptop lid:

button/lid)
case $3 in
close)
# The lock command need to be run as the user who owns the xscreensaver process and not as root.
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.
xs=$(ps -C xscreensaver -o user=)
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi
;;

To suspend the system and lock the screen using slimlock when the lid is closed:

Laptop Monitor Power Off

Adapted from the Gentoo Wiki comes this little gem. Add this to the bottom of /etc/acpi/actions/lm_lid.sh or to the button/lid section /etc/acpi/handler.sh. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.

If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.

With certain combinations of Xorg and stubborn hardware, xset dpms force off only blanks the display leaving the backlight turned on. This can be fixed using vbetool from the official repositories. Change the LCD section to:

On newer systems using systemd, X11 logins are no longer necessarily displayed in who, so the getuser function above does not work. An alternative is to use loginctl to obtain the required information, e.g. using xuserrun.