Events are triggered from the daemon when Hardware changes are recognised or user requests have been made.
Have a look into /etc/sysconfig/powersave/events where you may want to change the default behaviour how events get processed.
Events are triggered when: power/sleep button and the lid closing/opening. battery levels are exceeded the power source changes (AC/Battery) temperature limits are reached the user requests a suspend/standby sleeping state the machine resumes from a suspend/standby sleeping state the daemon is stopped/started the user manually requests a power save policy, so called scheme change the CPU usage was under a certain level for a specific time (configurable in cpufreq conf file) Any non thermal, battery, ac or button ACPI event had happend
If an event happens, the configured actions for this event (file see above) are processed from left to right.
There are internal (processed from the daemon internally) and external actions (executed scripts located in /usr/lib/powersave/scripts) user can assign to each event.
Internal actions (name is reserved, scripts must not named like that) currently are:
ignore (do nothing)
throttle (throttle cpu(s) to value POWERSAVE_MAX_THROTTLING if POWERSAVE_ALLOW_THROTTLING is set to "yes" -> scheme configuration variables)
dethrottle (unthrottle cpu(s))
reread_cpu_capabilities (Trigger re-evaluation of usable CPU speeds. There are machines, that cannot run on full speed when on battery. This internal event causes a re- evaluation of which speeds are available. Usually only makes sense in acadapter.*-events).
suspend_to_disk (Trigger the global.suspend2disk event)
suspend_to_ram (Trigger the global.suspend2ram event)
standby (Trigger the global.standby event)
do_suspend_to_disk (Actually tell kernel to do a suspend-to-disk. Should only be used for global.suspend2disk event)
do_suspend_to_ram (see do_suspend_to_disk) do_standby (see do_suspend_to_disk)
External actions are simply executables (typically scripts) placed in /usr/lib/powersave/scripts. The name of the executable is the event name. Example: put POWERSAVE_EVENT_OTHER="debug_events" into /etc/sysconfig/powersave/events to debug the hotplug events on some ASUS notebooks (the asus_acpi module has to be loaded) and watch /var/log/messages.
The scripts must use powersaved_script_return to tell powersaved when the event is finished. Otherwise no other event will be started until the previous event times out (after 120 seconds).
The syntax is:
powersaved_script_return "$EVENT_ID|$RET|$MESSAGE"
$EVENT_ID is the number given to the script as positional parameter $4. $MESSAGE is just informal, except for return codes 2 and 4. Possible return codes $RET are: 0 - execution of the event finished successfully 1 - execution of the event finished, but failed 2 - request a popup by the client, event not finished 3 - request a screenlock by the client, event not finished 4 - request a progress bar popup by the client, event not finished There may be additional codes added in the future.
This is example code to use in your own scripts: ———— #!/bin/bash # example script for events in powersaved # parameters: # - $1 event type # - $2 current scheme # - $3 ACPI event line # - $4 Event-ID. Needed for $SCRIPT_RETURN # # source helper_functions to get $PATH, $SCRIPT_RETURN (among others) . /usr/lib/powersave/scripts/helper_functions EV_ID=$4 # # this is stupid, you'd like to do something useful here :-) case $3 in button*) logger "button-event" ;; *) logger "non-button-event" $SCRIPT_RETURN "$EV_ID|1|example script failed" exit 1 ;; esac # always call $SCRIPT_RETURN before exiting: $SCRIPT_RETURN "$EV_ID|0|example script succeeded" exit 0 —————– There are various scripts in the contrib directory or have a look at the simple "debug_events" script in the scripts directory for other examples.