   #Top

                                      Powersave Documentation
     _____________________________________________________________________________________

   Next: Battery, Up: (dir)

Powersave Documentation / HOWTO

   This  packages  was  mainly  intended  for laptops. However more and more features (proper
   suspend/standby,  configure  ACPI  Buttons, processor frequency scaling (also supported on
   multi  processor  machines),  spinning down the hard disk, thermal management, ...) became
   available for workstations and even on servers.

   This  package  unifies  the  control  of power managing facilities on your PC. It supports
   hardware based on ACPI, APM, IDE-disks and CPU frequency scaling techniques. It takes over
   functionalities  of  the  apmd,  acpid, ospmd and cpufreqd (now called cpuspeed) packages.
   Therefore you should not install and you must not run daemons from these packages when you
   run the powersave daemon.
   One  exception  to this rule is acpid - since only one process can access /proc/acpi/event
   and  at least HAL and powersaved need ACPI events, we use acpid as an "event distributor".
   To  achieve  this you should configure acpid to not process any events, otherwise you will
   get  undefined  results  since powersaved also executes actions based on ACPI events. Just
   removing everything in /etc/acpi/events and putting an empty file named "default" in there
   should be enough for that.

   If  your  PC  does not contain all of the described hardware above (APM and ACPI are mutal
   exclusive)  you  should  still  run  this daemon to manage power saving related tasks. The
   overhead  is  small  and  you  will  be provided with a unique interface and configuration
   environment.  And you can still use this tool if some hardware should change (e.g. booting
   ACPI  instead  of  APM  when  kernel  provides  better  ACPI  support).  The  daemon  will
   automatically detect your hardware and support available features.

   Among others, the Powersave Daemon provides the following features:
     * Four  predefined  powersave schemes, each providing different settings which are fully
       configurable.  Adding  of  customized  schemes is also possible. The current scheme is
       automatically switched depending on the current power source.
          + Powersave
          + Performance
          + Acoustic
          + Presentation
     * Full  support  for cpu frequency scaling, either through kernel (ondemand governor) or
       within userspace. There are three predefined cpu policies.
          + Dynamic
          + Powersave
          + Performance
     * Battery management. This includes warning the admin/user when a critical battery state
       is  reached  and  automatic  shut  down  of  the  system  on  specific  events  (fully
       configurable).
     * Supporting Suspend to disk, Suspend to and ram and standby. This includes caring about
       setting up modules, services and a lot more.
     * Automatic cpu throttling depending on the current cooling policy
     * Full  featured  dbus  implementation  for  communication  with  various  clients  like
       kpowersave, wmpowersave, or gkrellm-powersave. More to come...

   Get the latest packages from https://sourceforge.net/projects/powersave

  Code Documentation

   If you are a developer and want to have a look at the code or the internal design, you may
   look at the Doxygen documentation.

  Outdated Documentation and Bug Reporting

   Be  aware  that  this  project  is  under  developement. If you find outdated or incorrect
   documentation  or  any  bug,  please  drop  us  a mail on powersave-devel@forge.novell.com
   (subscribe here:
   http://forge.novell.com/modules/xfmod/maillist/subscribe.php?group_id=1438&list=powersave-
   devel)

  Topics

     * Battery
     * Dynamic Processor Frequency Scaling
     * ACPI Buttons
     * Thermal Management
     * Suspend
     * Suspend with Nvidia Graphic Cards
     * Suspend To Ram
     * Suspend Security
     * Schemes
     * Powersave Events
     * Mapping Scripts to Events
     * Accessing Powersave Information via DBus
     * User Management - Security
     * Internals
     * Overriding the DSDT
     * Compiling and Installing the Sources
     * Distributions
     * Programs/Tools interacting with the Powersave Daemon
     * Version Specifics
     * Known Bugs
     * Further Work ToDo
     * FAQ
     * How to track down ACPI Kernel/BIOS Problems
     * How to get linked to or extend this Document
     * Lists and Links
     _____________________________________________________________________________________

   Next: Cpufreq, Previous: Top, Up: Top

1 Battery

  1.1 Battery Configurations

   The powersave daemon defines three battery states:
    1. WARNING
    2. LOW
    3. CRITICAL

   The user can set the limits when a battery state changes via these variables:
     * BATTERY_WARNING=12
     * BATTERY_LOW=7
     * BATTERY_CRITICAL=2

   in the /etc/powersave/battery file. Where the remaining capacity should be highest for the
   warning and lowest for the critical state.

   You  can  specify  an  action  what  should  happen when a battery state is sub-ceded (see
   Events) in the /etc/powersave/events file.

  1.2 Smart Battery Systems

   In  rare  cases  the  machine might have a smart battery bus system. This is currently not
   supported by the Linux kernel. However, a workaround exists which includes to dissassemble
   and  patch your DSDT (see DSDT). Rich Townsend has come up with a sourceforge project (see
   https://sourceforge.net/projects/sbs-linux/) that provides a patch for your DSDT. Be aware
   that  on  most  distributions  (SUSE  Linux,  Ubuntu,  Mandrake,  ...)  you do not need to
   recompile  your  kernel  (you can skip some steps described there), but you can simply add
   the DSDT to your initrd (see DSDT).

   AFAIK  a lot new ACER models do use the smart battery subsystems (Others might as well. If
   you have one you could mail me your machine model and I will setup a list if I have enough
   mail@renninger.de).

   You  find  a report/manual how to get smart battery support and other ACPI problems solved
   for the:
     * ACER 1680 and 1980 (1681 WLCi) http://www.whoopy.it/linux
     * ACER Extensa 3002 WLMI
     _____________________________________________________________________________________

   Next: Buttons, Previous: Battery, Up: Top

2 Dynamic Processor Frequency Scaling

   To  check  if  CPU  Frequency  scaling  is supported, start powersaved and have a look at:
   /sys/devices/system/cpu*/cpufreq -> there must exist files. If you don't find any, but you
   know    your    system    should    support    it,    browse/post    the   mailing   list:
   cpufreq@www.linux.org.uk.

   All   configuraton  variables  are  described  in  detail  in  the  /etc/powersave/cpufreq
   configuration file.

   You  may  want  to override these (or other) variables in the scheme_* files. A scheme and
   its configuration is activated when switching between AC and battery power source or could
   be switched by using:
     * powersave -x (to display available schemes)
     * powersave -e scheme_name (to switch to a specfic scheme)

   You  can  also  use  other front-ends like the kpowersave or wmpowersave clients to switch
   schemes.

   You  may  want to edit existing or create new schemes: On SUSE systems this can be done by
   using  the  YAST  power-management  module  (recommended) or by modifying the config files
   (/etc/powersave/scheme_*)  To  add an additional scheme by hand, just copy one scheme file
   and  rename  it  to scheme_"whatever" (in the same directory). Be sure that you modify the
   SCHEME_NAME variable in the file or the powersave daemon will be confused.

   Restart the powersaved or send a SIGHUP signal after you modified any config files.

   For  some  specific  machines, you need special hacks for loading the cpufreq modules. The
   ones  we  know  of are listed here, with a description of the chipset, so you can try this
   out  on similar machines. Note that you may need to reboot the machine (or at least unload
   all  cpufreq  modules  including  speedstep_lib  and  freq_table  and  after  that restart
   powersaved)  to get those working since powersaved does not unload the modules at stop and
   you  need  to  reload  the modules to make those settings effective). Also note that after
   changing modprobe.conf you need to run "depmod -a" first.

   List of machines:

   SHARP PC-AR10
   =============
   lspci excerpt:
   0000:00:00.0  Host  bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev
   03)
   0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
   /proc/cpuinfo excerpt:
   processor : 0
   vendor_id : GenuineIntel
   cpu family : 6
   model : 8
   model name : Pentium III (Coppermine)
   stepping : 3
   cpu MHz : 647.300
   cache size : 256 KB
   CPUFREQD_MODULE="speedstep-smi"
   CPUFREQD_MODULE_OPTS="smi_sig=1 smi_cmd=0x82 smi_port=0xb2"
   COMPAQ ARMADA E500
   ==================
   These are available in different flavours. I have seen one, (with a P III
   Coppermine, 800MHz) where adding "options speedstep_lib relaxed_check=1"
   to /etc/modprobe.conf.local and setting
   CPUFREQD_MODULE="speedstep-smi" was enough to get it going, another
   one (P III Coppermine, 700MHz) needs those and additional
   CPUFREQD_MODULE_OPTS="smi_cmd=0x82 smi_port=0xb2".
   This one has a (lspci):
   0000:00:00.0  Host  bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev
   03)
   0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
   and (/proc/cpuinfo):
   processor : 0
   vendor_id : GenuineIntel
   cpu family : 6
   model : 8
   model name : Pentium III (Coppermine)
   stepping : 6
   cpu MHz : 697.155
   cache size : 256 KB
   IBM Thinkpad T20 (model 2647-21G)
   =================================
   0000:00:00.0  Host  bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev
   03)
   0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
   processor : 0
   vendor_id : GenuineIntel
   cpu family : 6
   model : 8
   model name : Pentium III (Coppermine)
   stepping : 1
   cpu MHz : 647.401
   cache size : 256 KB
   P III Coppermine, 650MHz, just set CPUFREQD_MODULE="speedstep-smi".
     _____________________________________________________________________________________

   Next: Thermal, Previous: Cpufreq, Up: Top

3 ACPI Buttons

   If you are working on an ACPI system you can customize the behaviour of your ACPI buttons.
   These are:
     * Powerbutton
     * Sleepbutton
     * Lid open/close "button"

   Note  that  all  machines  should  have  a power button, most notebooks deliver usable lid
   open/close notifications and many have sleep buttons, but some do not, even if they have a
   button labeled "sleep", it might not work correctly.

   Search  for  the  button  event configuration variables in /etc/powersave/events (also see
   Events).

   You  may  also  be able to catch other (multimedia) buttons that are ACPI driven. However,
   this  mainly  depends  on your system. If your system provides ACPI driven buttons you can
   use one of the provided scripts or implement your own (see Scripts).
     _____________________________________________________________________________________

   Next: Suspend, Previous: Buttons, Up: Top

4 Thermal Management

   First: Thermal management is only available on ACPI systems.

   Second:  Thermal  management  is  buggy  on  a  lot of machines (mostly by BIOS, it's also
   possible  that  you  hit  a  kernel  bug,  see  Lists how to report a kernel bug to get it
   solved). It is also very buggy in powersaved, if something does not work, report it ;-)

  4.1 Examine your system

   Examine the directory(ies) in /proc/acpi/thermal_zone/*/
    1. Cooling Mode (currently rarely supported by BIOS)
       if cooling_mode is supported try out if the COOLING_MODE variable satisfies your needs
       (set  it  to  active  or  passive  in  your  scheme_* configuration files, see below -
       Configuration Variables).
    2. Overriding Trip Points
       If  cooling_mode is not supported, you have to adjust your trip points. Have a look at
       /proc/acpi/thermal_zone/*/trip_points or use powersave -T. Your system should at least
       support a passive, even better one or more active trip points (if not, nag your vendor
       to  export  temperature limits by BIOS, it is really easy, but a lot of vendors do not
       care much about the ACPI spec...) If your system supports trip points you can override
       the temperature limits for your needs (described below in Configuration Variables).
    3. Multiple Thermal Zones:
       If  you  have  multiple  thermal_zones  you  should  find  out which one refers to the
       processor first.
       E.g. like:
          + in one shell do: watch -n2 powersave -T
          + in another one: cat /dev/zero > /dev/null (high processor usage)
       if your processor supports CPU frequency control use powersave -f to speed and warm up
       your  processor  (powersave -A to switch back to dynamic mode). additionally you could
       close  the  slot to the fan (carefully...) The thermal zone(s) which temperature(s) is
       rapidly  increasing,  is(are)  the  interesting  one.  Adjust  the trip points of this
       thermal_zone (use number from powersave -T) using the variables described in 2.6.

  4.2 Configuration Variables

   Relevant   configuration   variables   are   in   /etc/powersave/thermal  and  the  scheme
   configuration files You may want to create e.g. a scheme cool/hot and activate it when you
   need  a  cool/fast  system  using  the kpowersave front-end or the -x -e parameters of the
   powersave binary.
    1. ENABLE_THERMAL_MANAGEMENT="yes"
       Relevant general configuration variables for each scheme: (/etc/powersave/scheme_*):
    2. COOLING_POLICY="passive"
          + active - The hardware is preferably cooled by the fan
          + passive  -  The  hardware is preferably cooled through lowering the cpu frequency
            and throttling. This is rarely supported by HW, See
            /proc/acpi/thermal_zone/*/cooling_mode
       The  cooling management is controlled by the kernel, powersaved has not much influence
       on this.
    3. THERMAL_CRITICAL_0="95"
       THERMAL_HOT_0="90"
       THERMAL_PASSIVE_0="35"
       THERMAL_ACTIVE_0_0="40"
       THERMAL_ACTIVE_0_1="42"
       Use  these  variables  to override the temperature trip point settings exported by the
       BIOS (in degrees Celsius, see /proc/acpi/thermal_zone/*/trip_points) The number at the
       end  of  each  variable defines the thermal zone for which the value should be active.
       Use  the  powersave  -T command to find supported thermal zones and their default trip
       point settings.
       You  might  want  to use the setDefaultTrippoints.sh script to fill your scheme_* conf
       files with your BIOS settings to easily override them.
       The  machine  is  switching  on  fans  when  active  trip point temperature limits are
       reached.
       When  reaching  the  passive trip point, the kernel will lower the CPU's frequency (if
       CPU  frequency  switching is supported by your CPU) and throttle the CPU down when the
       passive trip point is exceeded.
       By  default  the  passive  trip point (tp) is far above the active tps. For a cool and
       quiet  system  you  may want to change this similar to above example settings. However
       these  values  are  very HW dependant and you therefore have to fiddle around a bit to
       find out the best settings for your machine.
       Try  to  find  out  which  thermal  zone directly refers to the processor as described
       above.  A  low  value  for  passive  should  avoid fan activity but may slow down your
       machine  if  it  exceeds  the trip point's limit. The throttling is done by the kernel
       itself,  the  maximum  throttling variable is not used in case of the passive limit is
       reached.  Increase  the active trip points values (if supported) to additionally avoid
       fan activity.
       If a trip point is not supported by your BIOS (e.g. hot) you cannot use it -> write an
       email to your vendor he should support all of them, even you have a workstation.
     _____________________________________________________________________________________

   Next: SuspendNvidia, Previous: Thermal, Up: Top

5 Suspend

   Please read this notes before trying to use the suspend feature.

   First, some definitions so there's no confusion about the used terms:
     * suspend-to-disk:
       saves the actual state of the machine to disk and powers it down. After this, external
       power  and the batteries may be disconnected whithout losing data. At the next bootup,
       the  previous  state  is  resto-  red  and  the computer resumes where the suspend was
       triggered. This is also called "suspend to disk" (STD), the ACPI term for this is ACPI
       S4. There are two ways for doing this: one is calling the BIOS and letting it save the
       state  of  the machine, this works mostly with APM BIOSes (see notes below), the other
       way  is doing it ourselves in the kernel. The kernel implementation is called "swsusp"
       (for swap or software suspend) and is used with ACPI but can also be used for APM (see
       notes below).
     * suspend-to-RAM:
       most of the devices in the computer are deactivated (disk drives, graphics chips, even
       the  CPU)  and  only  the  RAM  is  powered  to keep its contents. At resume, only the
       individual  devices  need to be reinitialized and work continues relatively fast. This
       is also called "suspend to RAM" (STR). It depends on the particular hardware, how long
       a  notebook  can  be  kept in standby without need of an external power supply. Better
       machines will last several days while others run flat after only a few hours. The ACPI
       term for STR is ACPI S3.
     * standby:
       processes are stopped, some hardware is deactivated. The ACPI term for standby is ACPI
       S1. Not many machines support this state and the power savings are rather low.

   With ACPI it is pretty straightforward: the operating system has to prepare itself for the
   upcoming  sleep state and then enter it with (little) help of BIOS routines. This is still
   work in progress and not finished.

   Unfortunately,  things get a bit more complicated when using APM. With APM, there are only
   two states: standby and suspend. So with APM you get the following possible states:
     * standby - APM standby state
     * suspend  to RAM - APM suspend state. If the machine actually enters suspend to disk or
       suspend to RAM depends on the BIOS settings.
     * suspend to disk - machine suspends to disk using linux kernel swsusp method

   When the "suspend to RAM" routine is called, the BIOS actually decides if it does a STD or
   a  STR.  This  can  often  be selected in the BIOS setup. Also, STD on APM machines almost
   always  needs  a  special hibernation partition or a special file in a DOS partition which
   needs to be created with a vendor specific DOS or Windows program. On some machines with a
   Phoenix(R)  BIOS you can create the special partition with the linux program "lphdisk". To
   confuse  us even more, some machines (e.g. IBM Thinkpads) do STR or STD depending on which
   "suspend  button"  you  have pressed (Fn-F4 is STR, Fn-F12 is STD) but there is no way for
   the  powersave  daemon to select if it wants to do STR or STD via standard APM BIOS calls.
   We  have  therefore decided to implement swsusp also for APM machines that is triggered on
   the STD powersave methods (powersave -U, kpowersave: Suspend to Disk).

   Please note that suspend with ACPI is still experimental and may not work on all hardware.
   Especially suspend to RAM (ACPI S3) is very problematic on many machines. To avoid trouble
   for  unwary  users,  we  have disabled suspend and standby for normal users in the default
   configuration  on  non-notebook  machines.  If  you'd like to try out suspend, you have to
   change    the    values    of   DISABLE_USER_SUSPEND2DISK,   DISABLE_USER_SUSPEND2RAM   or
   DISABLE_USER_STANDBY  in  /etc/powersave/sleep  to  "no"  or  run the powersave command as
   superuser root.

   Warning:
   failing suspend/standby-cycles can lead to filesystem corruption and loss of data, so try
   this only if you know what you are doing. For the first tries it is advisable to close all
   open files and have only a small number of programs and services active on the machine.

   The  powersave  package  provides  a  uniform interface to both APM and ACPI but there are
   still  some  differences, which have to be adressed by the configuration settings. You can
   determine the powermanagement system used by your machine with the command "powersave -S".

   Using  ACPI, suspend to disk is known to work better than standby / suspend to RAM, so try
   this  first.  For  first  tests  it  is  advisable to set DEBUG to 7 or 15 to increase the
   verbosity  of  the powersaved and of the proxy scripts. You will find a lot of diagnostics
   output   in   /var/log/messages   after   restarting  powersaved.  Also,  there  are  some
   modules/services  which are known to cause problems with suspend, so be sure you installed
   the  newest  update  kernel.  3D  acceleration for graphic cards is known not to work with
   suspend  sometimes  (the binary only drivers from NVidia and ATI are a prominent example).
   However,  this  issue  is  being  worked  on  and  you already may be able to suspend with
   acceleration  enabled.  If  you  experience  any  hardware  problems  on suspend, we would
   appreciate  to  be informed about the hardware type that fails (for contact have a look at
   the end of this file).

   So now you are ready to go? Fingers crossed?
   Well,  let's  try.  Open a terminal and issue "powersave -U". If everything goes well, the
   machine  should  switch  to  a text console after a few seconds, showing you some progress
   marks  and  finally power off. Power it back on and it should begin a normal boot but then
   recognize  the  saved  image and resume. If everything goes well, the machine should be at
   the same state it was when the suspend started.

   What can go wrong?
     * The  machine  does not switch to the text console and shutdown, it seems just "nothing
       is happening". Before the actual suspend process starts, some drivers are unloaded and
       some  services  are  stopped.  If unloading of a module is not possible, a message box
       will  pop  up  and  a  message  is written to the log. Look into /var/log/messages for
       failures  to  unload  modules  or  stop services. The messages of the powersave daemon
       start  with  "powersaved"  or  "powersave".  If  you  see nothing in the log, look for
       hanging processes trying to remove modules and stop services with "ps auxfww".
     * The  machine reboots hard during resume. This is usually caused by incompatible device
       drivers. If it will retry the resume on the next boot, you have to pass the "noresume"
       option  at  the  boot  prompt  or  boot the "failsafe" menu entry once. Add suspicious
       modules in /etc/powersave/sleep to UNLOAD_MODULES_BEFORE_SUSPEND.
     * The  resume  seems to work fine, but some components do no longer work (e.g. USB Mouse
       or  the  network  card).  This  is  usually  caused  by drivers not fully implementing
       powermanagement  support and can often be worked around by unloading the driver module
       before    suspend    and    reloading   it   after   resume.   Add   the   module   to
       UNLOAD_MODULES_BEFORE_SUSPEND.

   To  help debugging and finding the "bad" modules, you'll find a list of modules which were
   loaded   and   information   about   memory  usage  before  your  last  suspend  event  in
   /var/log/suspend*.log.  A  state  file  that records which services were stopped and which
   modules unloaded is in /var/lib/suspend*-state.

   Since  suspend  is  in  constant  development and we don't have the possibility to test on
   every     available     hardware,     we    appreciate    any    feedback    either    via
   http://www.suse.com/feedback  or on the suse-laptop mailinglist to which you may subscribe
   via  http://www.suse.com (and even if you are trying suspend on a desktop machine, you are
   welcome  on  the suse-laptop mailinglist). Note, that this list is mostly german speaking,
   but you are generally welcome in english, too.
     _____________________________________________________________________________________

   Next: Suspend2Ram, Previous: Suspend, Up: Top

6 Suspend with Nvidia Graphic Cards

   To  use  suspend  with  the binary only driver for NVidia graphics cards, you need to take
   some  extra  precautions.  Note  that this apparently does not work on all NVidia graphics
   chipsets, YMMV:
     * download  the  NVidia  driver  with Yast Online Update, configure the card for 3D with
       sax2.  You  might  need  a  fairly  recent version of the NVidia driver, i tested with
       version       1.0.7167.       Reading       the       nvidia-installer-howto      from
       http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html is highly recommended.
     * put the line
       Option "NvAgp" "1"
       in the Device section, under 'Vendor Name "NVidia"'
     * do  not  load  the  vendor-agp module. To ensure this, remove any reference to the AGP
       modules from /etc/sysconfig/hardware:
       # cd /etc/sysconfig/hardware
       # grep agp *
       hwcfg-vpid-8086-3340:MODULE_0='intel-agp'
       now  edit  the  file  "hwcfg-vpid-8086-3340" (the one found with the grep command) and
       change  "STARTMODE='auto'"  to "STARTMODE='manual'". You might also want to remove the
       line "# HOTPLUG-FLAG: autocreated" to make this configuration persist future updates.
     * reboot, make sure that the agp module is no longer loaded by running
       # lsmod | grep agp
       there  should  be  no  vendor-agp  module  (e.g.  intel-agp, sis-agp,...) listed, only
       "agpgart".

   AGP support will only work with chipsets, which are supported by the nvidia kernel module.
   Otherwise     AGP    support    is    simply    disabled.    Check    this    with    "cat
   /proc/driver/nvidia/agp/status".  If  there is no line "Status: Enabled", then AGP support
   is not available. The graphics card will work without AGP, but performance will be bad.

   Note  that during suspend to disk, when the drivers get suspended, the display is switched
   off  (and  on notebooks this means also the backlight) but it is not switched back on when
   the  drivers are resumed to write the image. This means that you will not see any progress
   indicator  during  suspend  and  if  suspend fails (it should not :-) you will not see any
   error.  There  is  not much we can do about this right now, just wait until the disk stops
   writing and the machine turns itself off. After resume from suspend, the driver is resumed
   correctly and the display and backlight is turned back on.

   This  was tested on a SONY VAIO PCG-GRT995MP and a Dell D800 with both suspend to disk and
   RAM. It did not work on an older Dell Inspiron 8200.
     _____________________________________________________________________________________

   Next: SuspendSec, Previous: SuspendNvidia, Up: Top

7 Suspend To Ram

   ###############################################
   ### BIG FAT WARNING BIG FAT WARNING BIG FAT ###
   ###############################################

   severe file system corruption may occur which means: DANGER, DATA LOSS AHEAD.
   Please back up important data before trying suspend to RAM. In my experience,
   once you have found a setting that works, it is not dangerous at all, but
   you should keep an eye open. Use at your own risk.

   suspend  to  RAM with ACPI (S3) is still very experimental, but there are several machines
   that  are  known  to work. There are several "hacks" that can be tried to actually get the
   machine to resume (suspend is usually not the problem, just the resume ;-)

   Efforts  to  change  this  are  going on, work is being done to implement a "whitelist" of
   machines  that  are  known  to support suspend to RAM and the needed workarounds (if any).
   This  work  is  done  in the "suspend" package http://sourceforge.net/projects/suspend and
   there  in  the  "s2ram" binary. Support for s2ram is integrated into powersaved, it can be
   configured via configuration variables in /etc/powersave/sleep. On machines that are known
   to  s2ram,  no  configuration  should  be necessary. On machines that are unknown to s2ram
   (check  with  sram  -n  as  root),  you  need to set SUSPEND2RAM_FORCE=yes to override the
   detection, then configure the workarounds (if needed) with the variables described below:

   First,  there  are several kernel parameters, that can be tried out. Just add them to your
   "kernel"-line  in  /boot/grub/menu.lst.  More  information  about  those  can  be found in
   /usr/src/linux/Documentation/power/video.txt.

   You can try the following:
     * acpi_sleep=s3_bios
       calls the video BIOS during resume to initialize the video card.
     * acpi_sleep=s3_mode
       calls the video BIOS during resume to reset the text mode.
     * acpi_sleep=s3_bios,s3_mode
       combines the above.

   Also  if  it  "just does not work", it may be a good idea to try with the kernel parameter
   "vga=normal",  which  will  give  you  a  simple text console during boot (sorry, no fancy
   graphics  for  this  one). You need to remove the existing "vga=0x317" or similar from the
   kernel command line and add "vga=normal" instead. Only one "vga=..." should be present.
   To make the whole thing a bit more "interesting", the vga=normal can (and probably has to)
   be combined with the acpi_sleep=... parameters from above.

   The  acpi_sleep parameter can also be set at runtime in /proc/sys/kernel/acpi_video_flags,
   or  with the s2ram tool. In powersaved, the SUSPEND2RAM_ACPI_SLEEP variable sets this, see
   the comment in the configuration file for details.

   Another  possibility is to save and restore the VBE settings of the graphics card with the
   tool "vbetool". This is experimental and you should only use this if you know what you are
   doing. Example scripts for vbetool usage can be found in the contrib directory.

   Using  s2ram, VBE saving/restoring can be achieved with the SUSPEND2RAM_VBE_SAVE variable.
   VBE POST can be done with SUSPEND2RAM_VBE_POST. Again, see the comments in the config file
   for details.

   In  the  (not  too  distant)  past,  often the advice was given to suspend from a runlevel
   without  X,  but due to recent improvements with various X server modules, this may not be
   the  best  advice  anymore  since in fact on some machines only the X server is capable of
   bringing  the  graphics  card  back  correctly  from  suspend to RAM. On the Dell D600 for
   example, the display backlight stays off until the X server reinitializes the card.

   There  is  a  list of working machines and tricks how to get them work in the linux kernel
   Documentation.  If  the  linux  kernel  sources  are  installed,  the list can be found at
   /usr/src/linux/Documentation/power/video.txt.

   If  you  find  other  machines  that work with one of these (or if you cannot get machines
   mentioned  here  to  work  at  all)  feel  free  to  contact  us  via  the powersave-users
   mailinglist.
     _____________________________________________________________________________________

   Next: Schemes, Previous: Suspend2Ram, Up: Top

8 Suspend Security

   Warning:  if you are using crypto-filesystems, a suspend to disk will dump your passphrase
   for  these  to  the  swap  partition IN CLEAR TEXT. Either unmount these partitions before
   suspend or do not use suspend to disk at all. Sorry about that.
     _____________________________________________________________________________________

   Next: Events, Previous: SuspendSec, Up: Top

9 Schemes

   You can define different schemes that should take place if you plug/unplug the AC adapter.
   You  propably  want to ajust your system to drain less power when you work on battery, and
   to increase performance if you work on AC power.

   In /etc/powersave/common set the scheme that should be used:
     * AC_SCHEME="performance"
     * BATTERY_SCHEME="powersave"

   The  schemes  are  config  files  in  /etc/powersave.  Their  names  must be in the format
   scheme_SCHEMENAME.  In  the  above  case  there  are  at  least  two  scheme config files:
   scheme_performance  and  scheme_powersave  (provided).  You  can  set  up  your own scheme
   configurations,  modifiy  existing  (not  recommended,  at  least  backup them). SUSE also
   provides a configuration module with the YaST2 power-management module.

   Currently  you  can  influence  the  CPU  frequency  policy, IDE-disk power save features,
   temperature  settings  and  some  more.  Have  a look into the provided scheme files (e.g.
   /etc/powersave/scheme_powersave) for available variables and syntax.

   You  can  also  override  all  general  settings  from  any powewersave configuration file
   (/etc/powersave/*),  even reconfigure events (see Events). For example you could reset the
   battery  level limits with a "on_work" scheme. You also can e.g. shutdown the machine with
   the  one  scheme  and  suspend  the  machine  with another scheme when reaching a specific
   battery limit.

   You could also define your own scripts to be processed for specific events (see Scripts).
     _____________________________________________________________________________________

   Next: Scripts, Previous: Schemes, Up: Top

10 Powersave Events

   Events are triggered from the daemon when Hardware changes are recognised or user requests
   have been made.

   Have  a look into /etc/powersave/events where you may want to change the default behaviour
   how events get processed.

   The syntax is: EVENT="action1 action2 action3 ..."

   Events are triggered e.g. when:
     * power/sleep button presses 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 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) that can be assigned to each event.

   Internal actions (name is reserved, scripts must not be named like that) currently are:
     * ignore (do nothing)
     * throttle (throttle cpu(s) if throttling is enabled in this scheme)
     * dethrottle (unthrottle cpu(s))
     * reread_cpu_capabilities
       (Trigger  reevaluation  of  usable  CPU speeds. There are machines, that cannot run on
       full  speed when on battery. This internal event causes a reevaluation 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  from  a
       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  EVENT_OTHER="debug_events"  into  /etc/powersave/events to debug the hotkey
   events  on  some  ASUS  notebooks  (the  asus_acpi  module  has  to  be  loaded) and watch
   /var/log/messages for the output of the debug_events script..

   See the next chapter (Scripts) how to write your own scripts for events.
     _____________________________________________________________________________________

   Next: DBus, Previous: Events, Up: Top

11 Mapping Scripts to Events

   All  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, EV_ID (among others)
   . /usr/lib/powersave/scripts/helper_functions
   # Note: this sets a trap on "EXIT", so you must exit the script via the
   # (also provided) EXIT function after calling $SCRIPT_RETURN
   # If you don't call EXIT, the trap will call $SCRIPT_RETURN with return code 1
   #
   # 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  (the "example_event_script" has
   comments  on  what  is  provided  by  helper_functions)  or  have  a  look  at  the simple
   "debug_events" script in the scripts directory for other examples.
     _____________________________________________________________________________________

   Next: Security, Previous: Scripts, Up: Top

12 Powersave DBus specification

   Namespace: com.novell.powersave

   Interfaces:
    1. com.novell.powersave.manager
    2. com.novell.powersave.request
    3. com.novell.powersave.action

  12.1 The Manager Interface

   The  Manager interface is connection oriented Interface. Clients have to connect (and send
   their capabilities) to the daemon.

    12.1.1 Initial Connection by a Client at the Powersave Daemon

     * Interface: com.novell.powersave.manager
     * Member : "Connect"
     * Type : Method call with return

   0 capabilities int32 (sum of CAPABILITY_* defines, see powersave_clientsocket.h)

   ->  client  connection (message "connect" with the capabilities which can be handle by the
   connecting client).

   -> return type: boolean (TRUE on successful connection, else: FALSE)

   -> powersaved has to store the D-BUS sender string (e.g. ":1.5") of the "connect" message.
   Using  this  information  gives  the  +possibility  to  track  clients  whether  they died
   unexpectedly.

   Depending on the amount of capabilities the client has, the daemon now knows
     * what events and messages should be sent to the client.
     * what he can request from the client
     * what will be processed by the clients (e.g. screensaver capablities, ...)

   D-BUS Example:

   signal    sender=:1.5    ->    dest=(null   destination)   interface=com.novell.powersave;
   member=connect

   0 int32 "3"

   11 corresponds to the capabilities CAPABILITY_NOTIFICATIONS and CAPABILITY_SCREENLOCK
     * #define CAPABILITY_NOTIFICATIONS 1
     * #define CAPABILITY_SCREENLOCK 2
     * #define CAPABILITY_BRIGHTNESS 4

    12.1.2 Disconnect by a Client

     * Interface: com.novell.powersave.manager
     * Member : "Disconnect"
     * Type : Signal

   D-BUS Example:

   signal    sender=:1.5    ->    dest=(null   destination)   interface=com.novell.powersave;
   member=disconnect

   ->  According  to  the  sender  of the disconnect signal, the powersave daemon knows which
   capabilities are no longer available.

    12.1.3 Events triggerd by the Powersave Daemon

   Acpi events from /proc/acpi/events
     * Interface: com.novell.powersave.manager
     * Member : "AcpiEvent"
     * Type : Signal

   0 string (e.g. "button_power")

   Powersave events
     * Interface: com.novell.powersave.manager
     * Member : "PowersaveEvent"
     * Type : Signal

   0 string ("battery_low")

   Possible events:
     * "acadapter.offline"
     * "acadapter.online"
     * "button.sleep"
     * "button.power"
     * "button.lid.open"
     * "button.lid.closed"
     * "temperature.ok"
     * "temperature.active"
     * "temperature.passive"
     * "temperature.hot"
     * "temperature.critical"
     * "battery.normal"
     * "battery.warning"
     * "battery.low"
     * "battery.critical"
     * "battery.info" (something changed -> remaining percent/time should be reread)
     * "global.suspend2disk" (daemon has been asked to suspend and will do so now)
     * "global.suspend2ram"
     * "global.standby"
     * "global.resume.suspend2disk" (we are back from suspend)
     * "global.resume.suspend2ram"
     * "global.resume.standby"
     * "processor.performance" (The cpufreq policy changed to performance)
     * "processor.powersave"
     * "processor.dynamic"
     * "processor.busy" (The processor is not idle anymore)
     * "processor.idle" (The processor was idle for the last x seconds (by default 10))
     * "processor.notify" (Not sure now)
     * "daemon.start"
     * "daemon.terminate"
     * "daemon.scheme.change"  (scheme has been switched -> reread schemes or other info that
       could have changed)
     * "other" (Not sure now)

   Daemon or script progress (e.g. 'unloading modules 40%)
     * Interface: com.novell.powersave.manager
     * Member : "Progress"
     * Type : Signal

   Return types:
     * 0 string : Progress description (e.g. "unloading modules...")
     * 1 int32 : Progress (e.g. "10")

   Simple messages, error messages or notifications
     * Interface: com.novell.powersave.manager
     * Member : "Notification"
     * Type : Signal

   0 string (e.g. "Unable to unload module.")

   D-BUS Example:

   signal    sender=:1.5    ->    dest=(null   destination)   interface=com.novell.powersave;
   member=acpi_event 0 string "button.power"

   ->  according to its capabilities, the client has to set up matches in his filter function
   for the corresponding events triggered by the daemon.

   When  an event occurs the clients may want to use the Request interface to reread specific
   values  (e.g.  request  "rem_charg_time_battery"  after a event "battery.info", or request
   "schemes" after a event "daemon.scheme.changed"

  12.2 IV. Client Requests (Client -(request)-> Daemon -(response)-> Client)

   (Interface: com.novell.powersave.request)

   -> All requests do not have any parameters.

   Get all Powersave schemes
     * Interface: com.novell.powersave.request
     * Member : "SchemesGet"
     * Type : Method call with return

   Return types:
     * 0 string : array containing all available schemes
     * 1 uint8_t: index of current active scheme (use order of sent string array)
     * 2 uint8_t: index of battery scheme (use order of sent string array)
     * 3 uint8_t: index of AC scheme (use order of sent string array)

   Get a specific scheme description
     * Interface: com.novell.powersave.request
     * Member : "SchemesGetDescription"
     * Type : Method call with return

   Param:
     * 0 string : string has to match a scheme name.

   Return types:
     * 0 string : the requested scheme description

   Cpu frequency policy
     * Interface: com.novell.powersave.request
     * Member : "CpufreqPolicy"
     * Type : Method call with return

   Return type:
     * 0 string : ("dynamic", "performance", "powersave")

   Battery status
     * Interface: com.novell.powersave.request
     * Member : "BatteryState"
     * Type : Method call with return

   Return type:
     * 0 string : ("critical", "low", "warning", "normal", "no battery")

   Ac adapter power
     * Interface: com.novell.powersave.request
     * Member : "AcPower"
     * Type : Method call with return

   Return type:
     * 0 string : "on", "off", "unknown"

   If suspend to ram is allowed
     * Interface: com.novell.powersave.request
     * Member : "AllowedSuspendToRam"
     * Type : Method call with return

   Return type:
     * 0 boolean

   If suspend to disk is allowed
     * Interface: com.novell.powersave.request
     * Member : "AllowedSuspendToDisk"
     * Type : Method call with return

   Return type:
     * 0 boolean

   If standby is allowed
     * Interface: com.novell.powersave.request
     * Member : "AllowedStandby"
     * Type : Method call with return

   Return type:
     * 0 boolean

   Get current brightness level
     * Interface: com.novell.powersave.request
     * Member : "BrightnessGet"
     * Type : Method call with return

   Return type:
     * 0 int : the current brightness level

   Get current brightness in percent
     * Interface: com.novell.powersave.request
     * Member : "BrightnessGetPercent"
     * Type : Method call with return

   Return type:
     * 0 int : the current brightness level in percent

   Get available brightness levels
     * Interface: com.novell.powersave.request
     * Member : "BrightnessLevelsGet"
     * Type : Method call with return

   Return type:
     * 0 int : value containing the maximum brightness level

   Query list of device classes for runtime power management
     * Interface: com.novell.powersave.request
     * Member : "DpmClassesGet"
     * Type : Method call with return

   Return type:
     * 0 string : array containing all available classes

   Query list of devices for a specific device class
     * Interface: com.novell.powersave.request
     * Member : "DpmDevicesGet"
     * Type : Method call with return

   Param:
     * 0  string  :  string  has  to  match a class name. classes names can be requested (see
       above)

   Return type:
     * 0 string : array containing all available classes

  12.3 Daemon Actions (Client -(action)-> Daemon)

   (Interface: com.novell.powersave.action)

   Check whether daemon is up and replies
     * Interface: com.novell.powersave.action
     * Member : "Ping"
     * Type : Method call with return

   Set machine into suspend to disk mode
     * Interface: com.novell.powersave.action
     * Member : "SuspendToDisk"
     * Type : Method call with return

   Set machine into suspend to ram mode
     * Interface: com.novell.powersave.action
     * Member : "SuspendToRam"
     * Type : Method call with return

   Set machine into standby mode
     * Interface: com.novell.powersave.action
     * Member : "Standby"
     * Type : Method call with return

   Set cpu policy to performance
     * Interface: com.novell.powersave.action
     * Member : "CpufreqPerformance"
     * Type : Method call with return

   Set cpu policy to powersave
     * Interface: com.novell.powersave.action
     * Member : "CpufreqPowersave"
     * Type : Method call with return

   Set cpu policy to dynamic
     * Interface: com.novell.powersave.action
     * Member : "CpufreqDynamic"
     * Type : Method call with return

   Enabled a single CPU
     * Interface: com.novell.powersave.action
     * Member : "CpufreqCPUEnable"
     * Type : Method call with return

   Param:
     * 0 int : the CPU number to enable starting from 0

   Disable a single CPU
     * Interface: com.novell.powersave.action
     * Member : "CpufreqCPUDisable"
     * Type : Method call with return

   Param:
     * 0 int : the CPU number to disable starting from 0. CPU 0 can't be disabled ATM because
       it runs the main timer

   Set a powersave scheme
     * Interface: com.novell.powersave.action
     * Member : "SchemesSet"
     * Type : Method call with return

   Param:
     * 0  string  :  string  has  to  match a scheme name. scheme names can be requested (see
       above)

   Set brightness level
     * Interface: com.novell.powersave.action
     * Member : "BrightnessSet"
     * Type : Method call with return

   Param:
     * 0 int : the brightness level to set

   Set brightness level given in percent
     * Interface: com.novell.powersave.action
     * Member : "BrightnessSetPercent"
     * Type : Method call with return

   Param:
     * 0 int : the brightness level to set in percent

   Set brightness to minimum
     * Interface: com.novell.powersave.action
     * Member : "BrightnessMin"
     * Type : Method call with return

   Set brightness to medium
     * Interface: com.novell.powersave.action
     * Member : "BrightnessMed"
     * Type : Method call with return

   Set brightness to maximum
     * Interface: com.novell.powersave.action
     * Member : "BrightnessMax"
     * Type : Method call with return

   Increase brightness
     * Interface: com.novell.powersave.action
     * Member : "BrightnessUp"
     * Type : Method call with return

   Decrease brightness
     * Interface: com.novell.powersave.action
     * Member : "BrightnessDown"
     * Type : Method call with return

   Set a devices into powersave mode
     * Interface: com.novell.powersave.action
     * Member : "DpmDevicesSuspend"
     * Type : Method call with return

   Param:
     * 0  int  :  the  device  number  to  suspend. If not provided, -1 is taken which is the
       default

   Resume a devices from powersave mode
     * Interface: com.novell.powersave.action
     * Member : "DpmDevicesResume"
     * Type : Method call with return

   Param:
     * 0 int : the device number to resume. If not provided, -1 is taken which is the default

   Notify connected clients of any progress going on

  12.4 Return Messages

   All calls to the bus get a return/error message replied.

   Return messages include following types:
     * 0 uint_16 : Error ID
     * 0 string : Error message

   The error ids can be found in powersave_dbus.h as defines.

    12.4.1 If no error occured the return message includes (normal message):

     * 0 Error ID : REPLY_SUCCESS
     * 1 Error message : "success"

   If  an  error happens the message will be an error reply (as specified by dbus). Following
   errors can be checked for all method calls/signals:

   General Error
     * 0 Error ID : REPLY_GENERAL_ERROR
     * 1 Error message : "general error"

   No connection Error (The daemon is probably not running)
     * 0 Error ID : REPLY_CONNECTION
     * 1 Error message : "no connection"

   No rights Error (The client is not allowed to speak with the daemon)
     * 0 Error ID : REPLY_NO_RIGHTS
     * 1 Error message : "no rights"

   Invalid Paramet (The client sent bullshit)
     * 0 Error ID : REPLY_INVALID_PARAM
     * 1 Error message : "invalid param"

   Following request/actions may return specialised errors:

    12.4.2 Specialised Error Replies

   Following  errors  may occur on some actions/requests and must be checked by the client if
   such a action/request is made:
    1. Not supported (by HW):
          + 0 : REPLY_HW_NOT_SUPPORTED
          + 1 : "not supported"
       Interface: com.novell.powersave.action
          + Member : "SuspendToDisk"
          + Member : "SuspendToRam"
          + Member : "Standby"
          + Member : "CpufreqPerformance"
          + Member : "CpufreqPowersave"
          + Member : "CpufreqDynamic"
    2. Disabled by administrator:
          + 0 : REPLY_DISABLED
          + 1 : "disabled"
       Interface: com.novell.powersave.action
          + Member : "SuspendToDisk"
          + Member : "SuspendToRam"
          + Member : "Standby"
    3. Already set
          + 0 : REPLY_ALREADY_SET
          + 1 : "already set"
       Interface: com.novell.powersave.action
          + Member : "CpufreqPerformance"
          + Member : "CpufreqPowersave"
          + Member : "CpufreqDynamic"
    4. Does not exist
          + 0 : REPLY_INVALID_METHOD
          + 1 : "does not exist"
       Interface: com.novell.powersave.action
          + Member : "SchemesSet"
     _____________________________________________________________________________________

   Next: Internals, Previous: DBus, Up: Top

13 User Management - Security

   User management in current versions is done by DBus.

   A  configuration  file  (powersave.conf)  is  placed  in  the DBus configuration directory
   (current default: /etc/dbus-1/system.d). There you can configure who is allowed to connect
   to  the  DBus  interface  and  request  system  information  or e.g. trigger a suspend, or
   whatever.
     _____________________________________________________________________________________

   Next: DSDT, Previous: Security, Up: Top

14 Internals

  14.1 The Daemon

   The  heart  of  the  package  is  the daemon (/usr/sbin/powersaved). It listens for client
   requests  (normally from non-root users), listens for hardware changes and checks e.g. the
   CPU load to adjust the CPU frequency dynamically.

   There  are a fixed amount of events that the daemon my throw. The events could be triggerd
   by  the underlying hardware/kernel and the daemon just forwards them (e.g. ACPI events) or
   the  daemon can generate his own events when it recognises hardware changes (e.g. low/high
   CPU usage, changed battery levels, ...). See Events for an complete overview of all events
   and Scripts how you can use them in your own scripts and programs.

  14.2 The User Binary

   This binary (/usr/bin/powersave) provides general information about your system (APM/ACPI,
   battery, throttling, CPU frequency, ...).

   For  some  functionalities  you may need a running daemon. The binary then connects to the
   daemon  through  a  socket  and sends its requests (e.g. suspend, standby, change CPU freq
   policy, ...).

   The  modifications  could only be temporarily. They could e.g. be overridden by the policy
   of  the  daemon. E.g. if you plug/unplug AC adapter and another power scheme (see Schemes)
   is activated which then adjusts your power policy as you specified them for this scheme.

   The binary should mainly give you some information of your hardware. Please have a look at
   the manpage for details.

  14.3 The C-Libraries

   If  you  intend to write your own power manageing program you can make use of the provided
   libraries. All libraries are build statically and shared by the build system.

    14.3.1 Library that directly accesses the Hardware

   The  libpowersave.a/libpowersave.so  library  directly  accesses kernel functions (through
   /proc,  /sys  or ioctl) and could be very useful to gain hardware information (Have a look
   into powerlib.h for provided functions).

   The  library  is  currently  converted  to  make  use  of  HAL  functions to gain hardware
   information.  You may want to have a look at the code and also directly make use of HAL to
   gain  that  information.  However,  HAL lacks in some functionalities, therefore there are
   still functions that access /proc and /sys files directly.

    14.3.2 Library to send Requests to and retrieve HW Information from the Daemon

   Only exists in old versions, deprecated, don't use.
   Use the DBus interfaces instead.

    14.3.3 Library to register at the Daemon to retrieve Events asynchronously

   Only exists in old versions, deprecated, don't use.
   Use the DBus interfaces instead.

    14.3.4 Library to access the powersave daemon via DBus

   This  library should make it a bit easier to connect to the powersave daemon over the DBus
   system bus.

   However,  you  should make use of the DBus bindings directly if possible. They are offered
   in different languages (perl, QT, glib, phython, ...).

   See  DBus  what  information you can query from the powersave daemon and what actions(e.g.
   suspend, cpufreq policy, ...) you can trigger.
     _____________________________________________________________________________________

   Next: Compiling, Previous: Internals, Up: Top

15 Overriding the DSDT

  15.1 How it works

   The  DSDT  is one of several tables that is exported by the ACPI BIOS parts of your system
   from  ROM  to  RAM.  The  BIOS  tells  the Operating System where to find these tables and
   loads/uses them.

   The  DSDT table actually is code that can be executed by the Operating System and the BIOS
   to communicate with each other.

   This  code  (the DSDT) is byte-code (similar to compiled Java code) that is interpreted by
   the  kernel.  It  can easily be extracted, disassembled, modified (errors corrected, debug
   info  attached,  ...) and compiled to byte-code again. You can attach the modified DSDT to
   your  initrd/initramfs  (the  modular part of the kernel that is loaded very early at boot
   time).  After  the BIOS exported the ACPI tables to RAM and tells the kernel where to find
   them,  the  kernel  can replace e.g. the DSDT with your modfied/corrected one. Having said
   this, two points should be very important for you:

     * Your  BIOS Rom is not flashed. It's just replaced in RAM and booting another kernel/OS
       (without a modified DSDT) will use your manufacturer's DSDT as it was shipped.
     * The  DSDT  code is partly generated by your BIOS. If you add or remove memory you need
       to repatch (extract the original DSDT, modify it, ...) your changes.

   For some distributions you need a kernel patch to be able to do that. (not needed for most
   distributions  like  current versions of SUSE Linux, Ubuntu, Mandrake and others) You find
   the patch here: http://gaugusch.at/kernel.shtml

  15.2 How to check your DSDT for errors and debugging it

   You  can disassemble the byte-code of your DSDT. You then have a C-like bunch of functions
   that  were exported by your BIOS. You can modify and add debug statements to it, recompile
   it  and let the kernel override the one exported by BIOS with your modified/fixed one. The
   pmtools package has to be installed for this. You do this by:

    1. Extract all your ACPI BIOS tables by e.g.: acpidmp >/tmp/acpidmp
    2. Extract the DSDT from the tables: acpixtract dsdt /tmp/acpidmp >/tmp/dsdt
    3. Disassemble the dsdt: iasl -d /tmp/dsdt
    4. You now have a human readable C like file(dsdt.dsl) you can edit.
    5. You can recompile it by: iasl -sa dsdt.dsl
    6. Often  you  now  get obvious compile errors -> try to fix them. This is the time where
       you  should  have a look at the ACPI specification for help. See http://www.acpi.info/
       to download the newest version.
    7. You  can  add e.g. debug statements that are written to syslog if the code is executed
       by  adding  lines  like: Store ("Read battery", Debug). Be aware that your kernel must
       have  CONFIG_ACPI_DEBUG  set  and  you have to set the kernel ACPI debug values higher
       (see  ACPI_Debugging).  This is not the case for e.g. SUSE kernels for verions 9.3 and
       higher.
    8. After  successfully  compiling  your modified DSDT, c copy the DSDT.aml file where you
       want  to  (recommended: /etc/DSDT.aml). Edit /etc/sysconfig/kernel and modify the path
       to  a  DSDT  variable  where  you  copied your compiled DSDT (e.g. /etc/DSDT.aml). Run
       mkinitrd  (located  in  the mkinitrd package). Everytime you reinstall your kernel and
       use mkinitrd to create a initrd, your DSDT will be included and loaded at boottime.

  15.3 Finding and Adding an already fixed DSDT

   Find a DSDT for your laptop under: http://acpi.sourceforge.net/dsdt/tables/

   In the SUSE Linux distribution for example you can override your DSDT by:

    1. Download  the  table  for  your  machine.  Be  sure  that  it is unzipped and compiled
       (normally ending on AML [ACPI Machine Language], if so go to step 3.).
    2. If  it  is  ending on ASL (ACPI Source Language) , you still have to compile the table
       using  the  iasl  program  located  in the pmtools package. Compile the file: iasl -sa
       XXX.asl  You  also  find  the  newest  version  of  iasl  (Intel ACPI compiler) under:
       http://developer.intel.com/technology/iapc/acpi/downloads.htm
    3. Copy   the   DSDT.aml   where   you   want   to   (recommended:   /etc/DSDT.aml)  Edit
       /etc/sysconfig/kernel  and  modify  the  path to a DSDT variable where you copied your
       compiled  DSDT  (e.g.  /etc/DSDT.aml). Run mkinitrd (located in the mkinitrd package).
       Everytime  you  reinstall  your  kernel and use mkinitrd to create a initrd, your DSDT
       will be included and loaded at boottime.
     _____________________________________________________________________________________

   Next: Distributions, Previous: DSDT, Up: Top

16 Compiling and Installing the Sources

  16.1 Get the Sources

    16.1.1 Get the Tarball

   You can download SVN trunk tarballs via the webSVN frontend:
   http://forge.novell.com/modules/xfmod/svn/svnbrowse.php?repname=powersave

    16.1.2 Get the SVN Sources:

   svn checkout svn+ssh://anonymous@forgesvn1.novell.com/svn/powersave/trunk
   When prompted for the password, enter "anonymous". You currently have to enter this twice,
   once for ssh and once for subversion.
   The  module  you  wish  to  check out must be specified as modulename (either 'powersave',
   'kpowersave' or 'wmpowersave'). When prompted for the password, simply enter "anonymous".

   We'll  try  to let trunk stay in good shape all the time but well, you never know. Tell us
   if you find bugs or have problems compiling.

  16.2 Compiling

   In the powersave directory do:
    1. autoreconf -fi
       ./configure --prefix=/usr
       (./configure --help gives further instructions (recommended))
    2. If no error occurs type "make"
    3. change the user to root (su root) and type "make install"

  16.3 Needed Packages for Compiling

   This list is probably not complete, but gives an overview:

     * libstdc++
     * g++
     * autoconf
     * automake
     * libtool
     * ...
     _____________________________________________________________________________________

   Next: Clients, Previous: Compiling, Up: Top

17 Distributions

   We tested (or got reports for) the powersave package sources on following distributions:

                   SUSE Mandrake Debian Red Hat    Gentoo ALT-Linux
   Compiled        x    x        x      not tested x      x
   Installed/Works x    x        x      not tested x      x
   Package exists  x    N.A.     N.A.   N.A.       N.A.   x

   We  really  like  to see packages for more distributions. It cost me too much time to only
   install the above mentioned distributions to test-compile and install the sources.

   If  you  think  you  have knowledge enough on the distribution you are working on, you are
   welcome  to  submit some build scripts. We will integrate them into the SVN / tarballs and
   will try to build packages for new versions regularly.

   Distribution  specific  patches  will  gladly  be  committed  (as long as they don't break
   anything). Please contact me if you have any questions (mail@renninger.de)
     _____________________________________________________________________________________

   Next: Versions, Previous: Distributions, Up: Top

18 Programs/Tools interacting with the Powersave Daemon

   Currently  I  know  of  four clients that make use of or are based on the powersave daemon
   functionalities:
     * KPowersave
          + The graphical KDE front-end to powersave.
          + Works reliable and stable and got extensive testing.
          + Perfect for end-users.
       It  supports  switching between schemes, triggering suspend, shows the current battery
       level and warns if the battery runs low. It also offers configuration of X-based power
       functions such as DPMS and screensaver and some more.
       KPowersave is currently maintained by Danny Kukawka (danny.kukawka@web.de)
     * WMpowersave
       A  WindowMaker  applet  that  provides  basic  functionality  such  as  displaying and
       switching schemes, cpufreq policy and issuing suspend requests.
       The WMpowersave client is currently maintained by Holger Macht, (holger@homac.de).
     * YaST2 Powermanagement Module
       Provides configuration of most of the variables in /etc/powersave/ graphically.
       Only on SUSE right now.
     * GKrellm Plugin
       A  small  hack  from  Stefan  Seyfried  designed  to replace gkrellm's builtin battery
       monitor and set / display the cpufreq policy. Can also set the brightness on supported
       machines. Get the latest snapshot from
       http://forge.novell.com/modules/xfmod/svn/svnpage.php/powersave/

   KPowersave, WMpowersave and gkrellm-powersave are hosted on the powersave project pages at
   http://sourceforge.net/projects/powersave and
   http://forge.novell.com/modules/xfmod/project/?powersave
     _____________________________________________________________________________________

   Next: Bugs, Previous: Clients, Up: Top

19 Version Specifics

   Version 0.9
   1) Configuration
   dropped variables for schemes in /etc/sysconfig/powersave/schemes_*:
   POWERSAVE_DISABLE_DISPLAY_SETTINGS=
   POWERSAVE_DISABLE_SCREEN_SAVER=
   POWERSAVE_DISABLE_DPMS=
   POWERSAVE_DPMS_STANDBY=
   POWERSAVE_DPMS_SUSPEND=
   POWERSAVE_DPMS_OFF=
   These settings are no longer handled by the helper scripts but by the
   graphical clients like kpowersave (which can do this more easily).
   2) events / scripts in /usr/lib/powersave/scripts
   It was already possible in version 0.8 to put executables into
   /usr/lib/powersave/scripts and use the names of these executables as event
   names.
   In version 0.8, only the exit status of the script was used to determine
   success or failure. In version 0.9, you must now use
   /usr/lib/powersave/scripts/powersaved_script_return to tell powersaved if
   the event was executed successfully or not. Read more in README.events
   3) Clients
   Clients can now register with powersaved and get notified for specific
   events, so polling is no longer needed. Take a look at the "testclient"
   source code for further information.
   Clients can also be notified by e.g. proxy scripts to popup a messagebox,
   a progress bar or to lock the screen.
   #########################################################################
   Version 0.8
   1) Configuration
   configuration merged into one directory.
   powersave.conf (etc/) and common (/etc/sysconfig/powersave)
   have been merged into the files common, events, cpufreq, thermal,
   sleep and battery.
   Following config Variables have are new or have changed:
   New general variables:
   /etc/sysconfig/powersave/cpufreq:
   POWERSAVED_CPU_HYSTERESIS=
   POWERSAVED_CONSIDER_NICE=
   POWERSAVED_JUMP_CPU_FREQ_MAX_LIMIT=
   /etc/sysconfig/powersave/events:
   POWERSAVE_EVENT_DAEMON_SCHEME_CHANGE=
   POWERSAVE_EVENT_TEMPERATURE_CRITICAL=
   POWERSAVE_EVENT_TEMPERATURE_HOT=
   POWERSAVE_EVENT_TEMPERATURE_PASSIVE=
   POWERSAVE_EVENT_TEMPERATURE_ACTIVE=
   POWERSAVE_EVENT_TEMPERATURE_OK=
   /etc/sysconfig/powersave/thermal:
   POWERSAVE_ENABLE_THERMAL_MANAGEMENT=
   new variables for schemes in /etc/sysconfig/powersave/schemes_*:
   POWERSAVE_DISABLE_DISPLAY_SETTINGS=
   POWERSAVE_DISABLE_SCREEN_SAVER=
   POWERSAVE_DISABLE_DPMS=
   POWERSAVE_DPMS_STANDBY=
   POWERSAVE_DPMS_SUSPEND=
   POWERSAVE_DPMS_OFF=
   Because of confusing naming of sleep states those have been renamed:
   there was:
   suspend (ACPI S4, APM suspend)
   standby (ACPI S3, APM standby)
   now there is:
   suspend to disk (ACPI S4, APM suspend)
   suspend to ram (ACPI S3, APM suspend)
   standby (ACPI S1, APM standby)
   Therefore following variables changed in
   /etc/sysconfig/powersave/events and
   /etc/sysconfig/powersave/sleep:
   POWERSAVE_EVENT_GLOBAL_SUSPEND2DISK=
   POWERSAVE_EVENT_GLOBAL_SUSPEND2RAM=
   POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND2DISK=
   POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND2RAM=
   POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2DISK=
   POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2RAM=
   POWERSAVE_SUSPEND2DISK_RESTART_SERVICES=
   POWERSAVE_SUSPEND2RAM_RESTART_SERVICES=
   POWERSAVED_DISABLE_USER_SUSPEND2DISK=
   POWERSAVED_DISABLE_USER_SUSPEND2RAM=
   POWERSAVE_SUSPEND2DISK_DELAY=
   POWERSAVE_SUSPEND2RAM_DELAY=
   POWERSAVE_STANDBY_DELAY=
   2) Thermal Management
   Thermal management is supported from now on.
   see README.thermal.
   3) Switch Schemes Manually
   Schemes can now switched by hand using the powersave -x (overview of
   all schemes) and the powersave -e scheme_to_set (switch scheme)
   parameters.
   4) Socket Interface
   Other progs can now query the daemon for:
   AC state
   Suspend_to_disk enabled by admin
   Suspend_to_ram enabled by admin
   Standby enabled by admin
   Current cpufreq policy (powersave, dynamic, performance)
   Battery state (no_bat, normal, warning, low, critical)
   Battery charging state (unknown, charge/discharge, charge, discharge)
   Remaining percent battery capacity
   by one socket connect using the send_Action_get_States() and evaluate
   the return value using evaluate_States(int64_t states, int data_to_evaluate)
   (in libpower/powersave_daemonlib.c)
   Other progs can also switch query for a list of existing schemes using
   send_Action_get_all_Schemes(SchemeList* s) and switch schemes
   using the send_Action_ActivateScheme(const char *schemeName).
   5) Screen Saver / DPMS
   Screensaver (at least KDE) can be enabled/disabled and DPMS values can
   be modified depending on the current schemes.
   This allows to configure a presentation scheme (no DPMS/Screensaver)
   and a more effective powersave/battery scheme (more extreme DPMS values)
   Use the following variables in the scheme configuration files:
   POWERSAVE_DISABLE_SCREEN_SAVER
   POWERSAVE_DISABLE_DPMS
   POWERSAVE_DPMS_STANDBY
   POWERSAVE_DPMS_SUSPEND
   POWERSAVE_DPMS_OFF
   Version < 0.7
     _____________________________________________________________________________________

   Next: Todo, Previous: Versions, Up: Top

20 Known Bugs

   Nothing known at the moment, see FAQ.
     _____________________________________________________________________________________

   Next: FAQ, Previous: Bugs, Up: Top

21 Further Work ToDo

   These implementations are planned for the near future (any help is appreciated):

     * Make    use    of    cpufreq-utils    libraries.    They    can    be    found    here
       http://www.kernel.org/pub/linux/utils/kernel/cpufreq.
     * Get  rid  of  libpowersave  library  to access hardware through reading /sys /proc and
       ioctl. Use HAL instead.
     _____________________________________________________________________________________

   Next: ACPI_Debugging, Previous: Todo, Up: Top

22 FAQ

  22.1 Something went wrong I'm not sure what

   Have a look in /var/log/messages. All errors and warnings are logged there by default. You
   may  additionally  want  to  set  up  verbosity:  set DEBUG variable to 7 or even to 15 in
   /etc/powersave/common  and  restart  the  powersave  service/daemon  to isolate the error.
   Messages are again logged to /var/log/messages.

  22.2 I have ACPI enabled but buttons or/and battery states do not work as expected

  or I have ACPI Errors in dmesg and /var/log/messages

  or I don't see any battery information

   If  you experience ACPI related problems (normally logged in dmesg, or missing directories
   in /proc/acpi) (try: dmesg |grep -i acpi and watch out for errors).

   Please  visit  the homepage of your laptop vendor and update your BIOS. Nag your vendor to
   stick to the newest ACPI specifications in their BIOS!

   If  they  still occur you could try to find out why by debugging ACPI parts of your system
   (see ACPI_Debugging and to override your DSDT (see: DSDT).

  22.3 CPU frequency does not work

   See in the kernel source if your processor is supported:
   /usr/src/linux/Documentation/cpu-freq/*  (You  need  to install the kernel-source package)
   and  if  you  need  a special module or module option (see Cpufreq). If you need a special
   module/option use following variables:
     * CPUFREQD_MODULE=""
     * CPUFREQD_MODULE_OPTS=""

   in the /etc/powersave/cpufreq config file to set them.

  22.4 My battery has much shorter lifetime than when I bought my laptop

   As  older a battery as worse its capacity. But it may still work suitable, only the values
   delivered to the OS may be wrong.

   Try:
     * If  your  BIOS  does  support  refreshing  (emptying)  of your battery do it. Empty it
       totally  and  then  be sure you fully charge it again. You should refresh your battery
       regularly (see manual of your laptop).
     * Measuring  battery  values  is  more complex using ACPI. It could be that your battery
       shows  the  OS  a remaining capacity of zero, but could still work for an hour or even
       longer  (specially older batteries). Boot your system in APM mode (if supported) using
       the bootparam: acpi=off. This sometimes helps.

  22.5 My battery shows totally weird values, therefore power management is going crazy

   See section above.

  22.6 My processor does not run with maximum CPU frequency

   This  is  a  feature, not a bug. The processor's frequency is lowered if supported and the
   processor is idle. Try:
   cat /dev/zero > /dev/null &
   or
   glxgears

   The  system's  load  should  then be on 100% and the processor should run at highest speed
   (see cat /proc/cpuinfo)

  22.7 I cannot use the daemon related functions of the powersave binary

   If  you encounter following error using the powersave binary: Could not connect to daemon.
   Is the daemon running? Are you privileged to connect to the powersave daemon?

   You  probably  have  a  DBus  connection  problem.  Check the security config file for the
   powersave daemon in the DBus configuration (default: /etc/dbus-1/system.d/powersave.conf).

   Try to restart the DBus daemon.

  22.8 My system runs very slow

   Do powersave -c. If POWERSAVE is returned your CPU always runs on lowest frequency.

   A  slow  system  could  of  course have totally other reasons. Check your system (top, ps,
   ...).

   Have  a  look  in  /proc/acpi/processor/*/throttling. If the state is not T0 even your CPU
   load is high disable throttling in your scheme configuration files (see Schemes).

   Another  reason  could be that you use the p4-clockmod module (verify by: lsmod |grep p4).
   You  should  not  do  that. Throttling is done through another interface. Using both slows
   down  the  CPU unpredictable. Be sure this module is not used in /etc/powersave/cpufreq or
   loaded in any other way.
     _____________________________________________________________________________________

   Next: Extend, Previous: FAQ, Up: Top

23 How to track down ACPI Kernel/BIOS Problems

  23.1 Compile your Kernel with ACPI Debug set and track down ACPI problems

   If  you  have  ACPI problems on your machine, you should first have a look at DSDT. Try to
   disassemble  your  DSDT  and recompile it. If you have sever compiler errors, first try to
   fix  them,  override  your system's DSDT with your modified one and possibly your problems
   are gone. If this does not help go on reading this section.

   This section describes how you enable ACPI debug in SUSE kernels which was disabled due to
   performance  problems.  Other distributions may already have ACPI debug set or you need to
   do things slightly different.

   ACPI  debug  is  not  set anymore in SUSE kernels since version 9.3. Therefore you need to
   compile your own kernel with slightly other configs set:
    1. Install the kernel-source package.
    2. Move to the kernel's directory and copy the default configs:
       cd /usr/src/linux
       cp arch/i386/defconfig.default .config
       (Replace  i386  with your architecture e.g. x86_64 on 64 bits systems. Replace default
       (after  defconfig.)  with  smp  if you have a multi processor system or a dual core or
       hyperthreaded CPU).
    3. Edit the .config file and enable CONFIG_ACPI_DEBUG: You need to replace:
       "CONFIG_ACPI_DEBUG_LITE=y" with "# CONFIG_ACPI_DEBUG_LITE is not set"
       and
       "# CONFIG_ACPI_DEBUG is not set" with "CONFIG_ACPI_DEBUG=y"
       Be  careful,  that  the strings are identical to the ones above as the .config file is
       parsed  by  scripts.  You  could  use  make menuconfig and disable ACPI_DEBUG_LITE and
       enable ACPI_DEBUG with a little config front-end if you are unsure.
    4. compile and install the kernel (this might take a while):
       make
       make install
    5. You  might  want  to add new boot entry to your boot loader to be able to boot the new
       compiled  and  your old kernel. When using grub, modify your /boot/grub/menu.lst file.
       Simply  copy the first boot entry lines and make sure to replace the /boot/vmlinuz and
       /boot/initrd entries to point to the right files (/boot/vmlinuz-2.6.Kernel_Version, ls
       /boot and doing a copy paste helps).
    6. mkinitrd should not be necessary in newer SUSE versions. Shutdown the machine and boot
       the  newly  compiled  kernel.  (if you have ACPI problems during boot time you can now
       increase  the ACPI debug output by the boot options: acpi_dbg_level=XXX (see next step
       for XXX values).
    7. You can increase the debug output during runtime by:
       echo XXX >/proc/acpi/debug_level
       Be careful, too high values result in MB of debug output in syslog. Do:
       cat /proc/acpi/debug_level
       to see what levels you can choose. E.g.:
       echo 0x1F >/proc/acpi/debug_level
       adds ERROR, WARN, INIT, DEBUG_OBJECT (DSDT debug statements) and INFO.
    8. Now  load  the ACPI module you have problems with and have a look in /var/log/messages
       whether you find useful information.
    9. If  you think you find a kernel bug or an ugly BIOS problem that could be workarounded
       in  the  kernel,  please  file  a bugzilla bug at kernel.org and assign it to the ACPI
       component or ask on the acpi-devel mailing list (see Lists for URLs).
     _____________________________________________________________________________________

   Next: Lists, Previous: ACPI_Debugging, Up: Top

24 How to get linked to or extend this Document

  24.1 Get linked to this document

   If  you  have  some nice tricks e.g. how to get suspend to RAM working on your machine. Or
   maybe    other   special   tricks   for   special   machine   types,   please   write   to
   powersave-devel@forge.novell.com  or  if  you  are too lazy to subscribe directly write me
   mail@renninger.de.

  24.2 Extend this document and keep it up to date

   This  document is generated with the makeinfo tex parser. However, you don't need to speak
   tex to add or modify the sources.

   It's really easy to add some text.

   The  document is part of the powersave daemon documentation. The subversion repository can
   be  found  at  http://forge.novell.com/modules/xfmod/svn/svnpage.php/powersave/.  See  the
   section  Get  the  SVN  Sources at Compiling. Modify/Add files in the docs directory. Do a
   "makeinfo  -html powersave.tex" in the docs directory and see whether you have some errors
   (you  need to escape e.g. @ with @@). Send us the "diff -urN" of your modifications in the
   docs dir and we will include it.

   If you like to help, you are welcome to join the powersave devel mailinglist.
     _____________________________________________________________________________________

   Previous: Extend, Up: Top

25 Lists and Links

  25.1 Mailinglists

   If you have any trouble ask on one of the lists (email at where_to_subscribe):

   The Powersave Developer List:
   powersave-devel@forge.novell.com at
   http://forge.novell.com/mailman/listinfo/powersave-devel

   The Powersave Users List:
   powersave-users@forge.novell.com at
   http://forge.novell.com/mailman/listinfo/powersave-users

   The acpi-devel List:
   linux-acpi@vger.kernel.org at http://vger.kernel.org/vger-lists.html#linux-acpi

   The cpufreq List:
   cpufreq@lists.linux.org.uk at http://lists.linux.org.uk/mailman/listinfo/cpufreq

   The SUSE Laptop List (German mainly):
   suse-laptop@suse.de at http://www.suse.de/de/business/mailinglists.html

  25.2 Useful Links

   The powersave project is hosted on:
   http://forge.novell.com/modules/xfmod/project/?powersave (including SVN)
   and http://sourceforge.net/projects/powersave (new packages, discussions)

   If  you think you discovered an ACPI/cpufreq/or whatever related kernel bug, please assign
   to the kernel bugzilla at:
   http://bugzilla.kernel.org
   and report your bug against the ACPI subsystem (you will get help for sure).

   If you think you have a broken DSDT search:
   http://acpi.sourceforge.net/dsdt
   whether  you  find  a  fix.  You  can also submit a fixed DSDT there if you found a bug in
   yours.

   You can find the newest ACPI specification here:
   http://www.acpi.info/

   The  kernel  patches  (already included in most distributions - see DSDT) to override your
   DSDT at runtime is located at:
   http://gaugusch.at/kernel.shtml

   If  your  distribution  does  not  already  provide packages/tools to extract, compile and
   dissassemble  the  DSDT  you  find  the current iasl (Intel ACPI Source Language) compiler
   here:
   http://developer.intel.com/technology/iapc/acpi/downloads.htm

   and userspace tools to reach the DSDT you find here:
   http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils
