This manual describes the functionalities of the powersave package

   Copyright Thomas Renninger - SUSE Linux GmbH, 2005

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 at least you must
not run daemons from         these packages when you run the powersave
daemon!

   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.

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 in the
variables (default values): 		BATTERY_WARNING=12 		BATTERY_LOW=7
BATTERY_CRITICAL=2 	in the /etc/sysconfig/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 *Note Events::) in the /etc/sysconfig/powersave/events
file.

   	Asynchronous notification (/proc/acpi/battery/*/alarm) through ACPI
battery alarm interface prevents daemon of polling battery. On many
systems it resolves in a high CPU load because of bad hardware
solutions if battery information is read out.  If this interface is
supported you get the lowest necessary battery read out.  	If
FORCE_BATTERY_POLLING="yes" (default) is set to "no", 	the powersave
daemon does not poll the battery anymore, but waits 	for hardware
interrupts and ACPI events respectively.

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 *Note 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 *Note 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 modell 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'

2 Dynamic Processor Frequency Scaling
*************************************

If CPU Frequency scaling is supported you can check after the starting
the powersaved and having a look in: /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/sysconfig/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) and powersave -e
scheme_name (to switch to a specfic scheme)

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

   You may want to edit existing or create new schemes: This can be
done by using the YAST power-management module (recommended)  or (not
all variables are editable through YAST) modify the config files
themeselves (/etc/sysconfig/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".
3 ACPI Buttons
**************

	If you are working on an ACPI system you can customize the behaviour of
your ACPI 	buttons. These are: The Power and Sleep buttons and
the Lid open/close 	"buttons".

   	Search for the button event configuration variables in
/etc/sysconfig/powersave/events (also see *Note 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 ones 	(see *Note
Scripts::).

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 *Note Lists::
how to report a kernel bug to get it solved)

4.1 Examine your system
=======================

Examine the directory(ies) in /proc/acpi/thermal_zone/*/

  1. Cooling Mode   (currently rarely support 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 not you have to adjust your trip
     points.    Have a look at /proc/acpi/thermal_zone/*/trip_points or
     better 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.    Ajust 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/sysconfig/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.    (Only cooling mode is
configurable through YAST (power-management module)   for overridding
your thermal trip points.)

  1.   ENABLE_THERMAL_MANAGEMENT="yes"

     _Relevant general configuration variables for each scheme:
     (/etc/sysconfig/powersave/scheme_*):

  2.   COOLING_POLICY="passive"

     Activ - The hardware is preferably cooled by the fan.    Passiv -
     The hardware is preferably cooled through   This is rarely
     supported by HW.  	    See /proc/acpi/thermal_zone/*/cooling_mode
     The cooling management is controlled by the kernel   the
     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 the variables to override the temperature trip point settings
     exported   by BIOS (in degree Celcius).    (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 out
     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.

5 Suspend
*********

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

   Also, please take a look at the other README.* files in this
documentation directory since they may cover other aspects related to
suspend.

   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 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/sysconfig/powersave/sleep to "no".

   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".

   With APM, you rarely need to stop services and unload modules before
suspending to ram or disk, so there should be no need for further
configuration, you can probably just empty the corresponding variables
in /etc/sysconfig/powersave/sleep. Note that many drivers have changed
in kernel 2.6 with regard to power management and may behave differently
now compared to kernel 2.4 (This only applies for the APM sleep methods
standby and suspend to disk).

   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 NVidia drivers 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).

   To use swsusp with ACPI or APM there must exactly one swap partition
be configured. This partition must be passed to the kernel via the
"resume="-paramerter, usually in /boot/grub/menu.lst or /etc/lilo.conf
(this is done automatically by YaST during the installation).

   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/sysconfig/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 which
records which services were stopped and which modules unloaded is in
/var/lib/suspend*-state.

   Since software 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.

   November 2004, Stefan Seyfried (<seife@suse.de>)

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.

   Have a lot of fun!

   Stefan Seyfried (<seife@suse.de>).

   May 2005

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.

   Hello,

   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 ;-)

   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.

   Another possibility is to save and restore the VBE settings of the
graphics card with the tool "vbetool". This is very 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.

   A grub entry with those settings could look like this:

   title SUSE LINUX 9.3     kernel (hd0,1)/boot/vmlinuz root=/dev/hda3
selinux=0 splash=silent resume=/dev/hda2 showopts vga=normal
acpi_sleep=s3_bios     initrd (hd0,1)/initrd

   Note that i put the changed options after the "showopts" keyword, so
i can easily see (and change) them at the boot prompt.

   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.

   The machines listed below are reported to be working or tested by
us, they often need one of the "tricks" listed above which is noted
along with them.  As those machines are often available in different
"generations" i tried to describe them a little closer with the
information available from lspci or dmidecode, such as an exact model
number or the exact type of the graphics card. If you have a similar
graphics card, you might get by with the same "trick".

   Machine specific "tricks":

     Dell D600 (ATI R250Lf)
     works with "vga=normal", X server brings back the backlight

     Compaq Armada E500
     no tricks needed, suspend2ram and standby works "out of the box".
            (P3-700,ATI Rage Mobility P/M)

     IBM Thinkpad R32
     no tricks needed, "works out of the box".          (Type 2658-MMG)

     IBM Thinkpad T20
     	no tricks needed, but console is corrupted after resume.
     vga=normal works better.          (Type 2647-44G, savage graphics)

     IBM Thinkpad T41p
     acpi_sleep=s3_bios,s3_mode         (Type 2373-W6M, ATI M10NT,
     [FireGL Mobility T2])

     IBM Thinkpad X40
     acpi_sleep=s3_bios,s3_mode         (Type 2371-7JG)

     IBM Thinkpad 600e
     no tricks needed, but after resume a switch from X to console and
     back is needed (or vbetool restore).          (Type 2645-5BG)

     Toshiba Satellite 4080XCDT
     acpi_sleep=s3_mode. suspend2ram and standby works

     ASUS L2400D
     acpi_sleep=s3_mode. suspend2ram and standby works.

     Sharp PC-AR10
     no tricks. The display backlight does not switch off, 	but
     if you suspend via "lid close", the light is 	turned off by the
     switch.

     HP Omnibook 4150
     no tricks, just works. standby works, too.

     ACER Travelmate 803LCi
     vga=normal, X server brings back the backlight         (ATI R250Lf)

     ACER C300 Tablet PC
     vesafb with "vbetool vbestate save / restore"         (i855
     centrino)

     FSC Amilo M7400 (i855)
     vesafb with "vbetool vbestate save / restore"

     SONY PCG-GRT995MP (nv)
     no tricks, just works with the "nv" X driver. For         the
     binary NVidia driver, please read README.NVidia.

     SONY VGN-FS115B
     acpi_sleep=s3_bios,s3_mode.          If you used i855resolution
     during boot to get a fullscreen X display, you also need to use
     something like contrib/video_bios_suspend and
     contrib/video_bios_resume to re-patch the BIOS during resume
     before switching back to X. Some documentation is provided in
     those example scripts.

   Often, the "acpi_sleep=s3_mode" is not strictly necessary since the X
server will reset the text mode also, so it is sometimes more a
"correctness issue" than a really needed fix.

   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 suse-laptop mailinglist or directly.

   Good luck and

   Have a lot of fun... :-)

   Stefan Seyfried (<seife@suse.de>)

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.

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/sysconfig/powersave/common set the scheme that should be
used: 		AC_SCHEME="performance" 		BATTERY_SCHEME="powersave"

   	The schemes are config files in /etc/sysconfig/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/sysconfig/powersave/scheme_powersave) for available
variables and syntax.

   	You can also override all general settings from any powewersave
configuration file (/etc/sysconfig/powersave/*), even reconfigure
events (see *Note 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 *Note Scripts::).

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/sysconfig/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 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 			MAX_THROTTLING if
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 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.

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

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.

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

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.

   *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)

   *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"

   *Remaining percent of battery charge*
   * Interface: com.novell.powersave.Request

   * Member   : "BatteryRemainingPercent"

   * Type     : Method call with return

   Return type:
   * 0 uint8_t

   *Remaining time untile battery is empty*
   * Interface: com.novell.powersave.Request

   * Member   : "BatteryRemainingTime"

   * Type     : Method call with return

   Return type:
   * 0 uint_t16: minutes

   *Remaining time untile battery is fully charges*
   * Interface: com.novell.powersave.Request

   * Member   : "BatteryRemainingChargingTime"

   * Type     : Method call with return

   Return type:
   * 0 uint_t16: minutes

   *The current charging state*
   * Interface: com.novell.powersave.Request

   * Member   : "BatteryChargingState"

   * Type     : Method call with return

   Return type:
   * 0 string : "charging", "discharging", "charging discharging",
     "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

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

   *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)

   *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"

        * Member   : "BatteryRemainingPercent"

        * Member   : "BatteryRemainingChargingTime"

  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"


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.

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 *Note
Events:: for an complete 	overview of all events and *Note
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 *Note 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 sends Requests to and retrieves HW Information from the Daemon and
------------------------------------------------------------------------------------

	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 *Note DBus:: what information you can query from the powersave
daemon and 	what actions(e.g. suspend, cpufreq policy, ...) you
can trigger.

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:




   bullet 			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.

   bullet 			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 *Note 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.



16 Compiling and Installing the Sources
***************************************

Installation Instructions *************************

   Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005
Free Software Foundation, Inc.

   This file is free documentation; the Free Software Foundation gives
unlimited permission to copy, distribute and modify it.

   Basic Installation ==================

   These are generic installation instructions.

   The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation.  It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions.  Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, and a
file `config.log' containing compiler output (useful mainly for
debugging `configure').

   It can also use an optional file (typically called `config.cache'
and enabled with `-cache-file=config.cache' or simply `-C') that saves
the results of its tests to speed up reconfiguring.  (Caching is
disabled by default to prevent problems with accidental use of stale
cache files.)

   If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release.  If you are using the cache, and at
some point `config.cache' contains results you don't want to keep, you
may remove or edit it.

   The file `configure.ac' (or `configure.in') is used to create
`configure' by a program called `autoconf'.  You only need
`configure.ac' if you want to change it or regenerate `configure' using
a newer version of `autoconf'.

   The simplest way to compile this package is:

   1. `cd' to the directory containing the package's source code and
type      `./configure' to configure the package for your system.  If
you're      using `csh' on an old version of System V, you might need
to type      `sh ./configure' instead to prevent `csh' from trying to
execute      `configure' itself.

   Running `configure' takes awhile.  While running, it prints some
messages telling which features it is checking for.

   2. Type `make' to compile the package.

   3. Optionally, type `make check' to run any self-tests that come with
    the package.

   4. Type `make install' to install the programs and any data files and
    documentation.

   5. You can remove the program binaries and object files from the
source code directory by typing `make clean'.  To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'.  There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers.  If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.

   Compilers and Options =====================

   Some systems require unusual options for compilation or linking that
the `configure' script does not know about.  Run `./configure -help' for
details on some of the pertinent environment variables.

   You can give `configure' initial values for configuration parameters
by setting variables in the command line or in the environment.  Here
is an example:

   ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix

   *Note Defining Variables::, for more details.

   Compiling For Multiple Architectures
====================================

   You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory.  To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'.  `cd' to the
directory where you want the object files and executables to go and run
the `configure' script.  `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.

   If you have to use a `make' that does not support the `VPATH'
variable, you have to compile the package for one architecture at a
time in the source code directory.  After you have installed the
package for one architecture, use `make distclean' before reconfiguring
for another architecture.

   Installation Names ==================

   By default, `make install' installs the package's commands under
`/usr/local/bin', include files under `/usr/local/include', etc.  You
can specify an installation prefix other than `/usr/local' by giving
`configure' the option `-prefix=PREFIX'.

   You can specify separate installation prefixes for
architecture-specific files and architecture-independent files.  If you
pass the option `-exec-prefix=PREFIX' to `configure', the package uses
PREFIX as the prefix for installing programs and libraries.
Documentation and other data files still use the regular prefix.

   In addition, if you use an unusual directory layout you can give
options like `-bindir=DIR' to specify different values for particular
kinds of files.  Run `configure -help' for a list of the directories
you can set and what kinds of files go in them.

   If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `-program-prefix=PREFIX' or `-program-suffix=SUFFIX'.

   Optional Features =================

   Some packages pay attention to `-enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `-with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System).  The
`README' should mention any `-enable-' and `-with-' options that the
package recognizes.

   For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `-x-includes=DIR' and
`-x-libraries=DIR' to specify their locations.

   Specifying the System Type ==========================

   There may be some features `configure' cannot figure out
automatically, but needs to determine by the type of machine the
package will run on.  Usually, assuming the package is built to be run
on the _same_ architectures, `configure' can figure that out, but if it
prints a message saying it cannot guess the machine type, give it the
`-build=TYPE' option.  TYPE can either be a short name for the system
type, such as `sun4', or a canonical name which has the form:

   CPU-COMPANY-SYSTEM

   where SYSTEM can have one of these forms:

   OS KERNEL-OS

   See the file `config.sub' for the possible values of each field.  If
`config.sub' isn't included in this package, then this package doesn't
need to know the machine type.

   If you are _building_ compiler tools for cross-compiling, you should
use the option `-target=TYPE' to select the type of system they will
produce code for.

   If you want to _use_ a cross compiler, that generates code for a
platform different from the build platform, you should specify the
"host" platform (i.e., that on which the generated programs will
eventually be run) with `-host=TYPE'.

   Sharing Defaults ================

   If you want to set default values for `configure' scripts to share,
you can create a site shell script called `config.site' that gives
default values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists.  Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.

   Defining Variables ==================

   Variables not defined in a site shell script can be set in the
environment passed to `configure'.  However, some packages may run
configure again during the build, and the customized values of these
variables may be lost.  In order to avoid this problem, you should set
them in the `configure' command line, using `VAR=value'.  For example:

   ./configure CC=/usr/local2/bin/gcc

   causes the specified `gcc' to be used as the C compiler (unless it is
overridden in the site shell script).  Here is a another example:

   /bin/bash ./configure CONFIG_SHELL=/bin/bash

   Here the `CONFIG_SHELL=/bin/bash' operand causes subsequent
configuration-related scripts to be executed by `/bin/bash'.

   `configure' Invocation ======================

   `configure' recognizes the following options to control how it
operates.

   `-help' `-h'      Print a summary of the options to `configure', and
exit.

   `-version' `-V'      Print the version of Autoconf used to generate
the `configure'      script, and exit.

   `-cache-file=FILE'      Enable the cache: use and save the results
of the tests in FILE,      traditionally `config.cache'.  FILE defaults
to `/dev/null' to      disable caching.

   `-config-cache' `-C'      Alias for `-cache-file=config.cache'.

   `-quiet' `-silent' `-q'      Do not print messages saying which
checks are being made.  To      suppress all normal output, redirect it
to `/dev/null' (any error      messages will still be shown).

   `-srcdir=DIR'      Look for the package's source code in directory
DIR.  Usually      `configure' can determine that directory
automatically.

   `configure' also accepts some other, not widely useful, options.  Run
`configure -help' for more details.

17 Distributions
****************

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


   		                   SUSE    Mandrake    Debian  Red     Gentoo  ALT-Linux
                                           Hat             
Compiled       x       x           x       not     x       x
                                           tested          
Installed/Worksx       x           x       not     x       x
                                           tested          
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.  I'll
integrate them into CVS and will 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>)

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:




  1. 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 battery limits are
     sub-ceeded.  	It also offers configuration of X-based power
     functions such as 	DPMS and screensaver and some more.

     	The KPowersave daemon is currently maintained by Danny Kukawka
     (<danny.kukawka@web.de>)



  2. WMPowersave

     	The graphical Window Maker front-end.  	Similar
     functionalities as KPowersave, but slightly restricted 	due
     the fact that it is a Window Maker applet.

     	The WMPowersave client is currently maintained by Holger Macht,
     who also implemented the client connection stuff in the powersave
     daemon (<holger@homac.de>).



  3. Yast Power-Management Modul

     	Let the end-user configure most of the variables in
     /etc/sysconfig/powersave/* graphically.  	Unfortunately
     SUSE only of course.



  4. GKrellm Plugin

     	A small hack from Stefan Seyfried. Get the latest CVS snapshot from
     `http://forge.novell.com/modules/xfmod/cvs/cvsbrowse.php/powersave/gkrellm-powersave/'



   	The KPowersave and WMPowersave project are also hosted on the
powersave project's sites at `http://sourceforge.net/projects/powersave'
and `http://forge.novell.com/modules/xfmod/project/?powersave'

19 Version Specifics
********************

# Author Thomas Renninger #        Stefan Seyfried

   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

20 Known Bugs
*************

Nothing known at the moment, see *Note FAQ::.

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.



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/sysconfig/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 *Note ACPI_Debugging:: and to override 		your
DSDT (see: *Note 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 *Note Cpufreq::). If you need 		a special
module/option use following variables: 			CPUFREQD_MODULE=""
CPUFREQD_MODULE_OPTS="" 		in the /etc/sysconfig/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 *Note 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/sysconfig/powersave/cpufreq
   or loaded in any other way.

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 *Note 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. 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 *Note Lists:: for URLs).


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 CVS
can be found at
`http://forge.novell.com/modules/xfmod/project/?powersave'.  See the
section Get the CVS Sources at *Note Compiling::.  Modify/Add files in
the docs directory.  Do a: makinfo -html powersave.tex in the docs
directory and see whether you have some errors (you need to escapce
e.g. @ with @@).  Send us the "diff -urN" of your modifications in the
docs dir and we will include it.

   If you like to and prove some ambitions your welcome to join and
help extending the powersave daemon with extended rights on the
sourceforge/novellforge powersave project.

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 acpi-devel List:

   	<Acpi-devel@lists.sourceforge.net> at
`https://lists.sourceforge.net/lists/listinfo/acpi-devel'

   	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 CVS)

   	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 find the newest ACPI specification here:

   	`http://www.acpi.info/'

   	The kernel patches (already included in most distributions - see
*Note 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'

