* Author:  Thomas Renninger
* Contact: trenn@suse.de, mail@renninger.de
*
* Sources hosted on: forge.novell.com - search for the powersave package...
*

*** This version is currently in beta phase and still could contain some bugs,  ***
***	specially on a weird BIOS !                                             ***


******* T H E    P O W E R S A V E    P A C K A G E **************



_1) TABLE OF CONTENTS_

	2) PURPOSE, SUPPORTED HARDWARE AND FEATURES
		2_1) APM/ACPI
			2_1_1) PROPER SUSPEND/STANDBY
			2_1_2) THREE USER DEFINED BATTERY STATES (WARNING, LOW, CRITICAL)
			2_1_3) ADJUSTED POWER CONSUMPTION FOR WORKING ON AC/BATTERY POWER
		2_2) ADDITIONAL ACPI FEATURES
		2_3) CPU FREQUENCY SCALING
	3) HOW IT WORKS, GENERAL DESCRIPTION
		3_1) THE DAEMON
		3_2) THE PROXY
		3_3) THE USER BINARY
		3_4) THE LIBRARY

	4) KERNEL CONFIGURATION
	5) FAQ, WORKAROUNDS FOR BUGGY HARDWARE
	6) TO_DO




_2) PURPOSE, SUPPORTED HARDWARE AND FEATURES_


	This packages is mainly for laptops. Its main purpose is to save power
	when working on battery. However some additional features (proper
	suspend/standby, configure ACPI Buttons, ...)  may also be interesting
	for workstations or even server (e.g. spindown IDE-disks).

	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.



  *2_1) APM/ACPI*

    2_1_1) PROPER SUSPEND/STANDBY

	The package provides a proper interface to unload critical modules and
	to stop critical services before a suspend or standby is triggered.
	When the machine resumes they are loaded/started again.

	Add services which should be started/stopped into following
	variables (default configuration):
		POWERSAVE_SUSPEND_RESTART_SERVICES="pcmcia hotplug"
		POWERSAVE_STANDBY_RESTART_SERVICES="pcmcia hotplug"
	and modules that should be unloaded/loaded into:
		POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND="uhci_hcd ohci_hcd ehci_hcd raw1394 ohci1394 ieee1394"
		POWERSAVE_UNLOAD_MODULES_BEFORE_STANDBY="uhci_hcd ohci_hcd ehci_hcd raw1394 ohci1394 ieee1394"
	in the /etc/sysconfig/powermanage/common configuration file

	be sure that the following default options for processing
	suspend/standby occurence/resume events are also set in this file:
		POWERSAVE_EVENT_GLOBAL_SUSPEND="prepare_suspend"
		POWERSAVE_EVENT_GLOBAL_STANDBY="prepare_standby"
		POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND="restore_after_suspend"
		POWERSAVE_EVENT_GLOBAL_RESUME_STANDBY="restore_after_standby"
	in the /etc/sysconfig/powermanage/common configuration file	

	and that the events are assigned to powersave_proxy script 
	that has to be executed if such events happen (and reacts
	according to the above options to those events):
		global.suspend=/usr/sbin/powersave_proxy
		global.standby=/usr/sbin/powersave_proxy
		global.resume.suspend=/usr/sbin/powersave_proxy
		global.resume.standby=/usr/sbin/powersave_proxy
	in /etc/powersave.conf

	ACPI suspend/standby needs support from kernel, which gets more and
	more stable.  However on a ACPI system you should have at least kernel
	2.6.0 running!
			
	You also need to have the bootparam:  
		*resume=/dev/swap_partition*
	set when suspending with ACPI!

			
    2_1_2) THREE USER DEFINED BATTERY STATES (WARNING, LOW, CRITICAL)

	The user can set the limits when a battery state changes in the variables:
		POWERSAVED_BATTERY_WARNING=20
		POWERSAVED_BATTERY_LOW=10
		POWERSAVED_BATTERY_CRITICAL=5
	in the /etc/sysconfig/powermanage/powersave 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.  Set a program/script you want to be executed in:
		battery.normal=/usr/sbin/powersave_proxy
		battery.warning=/usr/sbin/powersave_proxy
		battery.low=/usr/sbin/powersave_proxy
		battery.critical=/usr/sbin/powersave_proxy
	in the /etc/powersave.conf file.

	If you have the powersave_proxy specified you still have some
	additional features what should happen on which event in the
	/etc/sysconfig/powermange/common file:
		POWERSAVE_EVENT_BATTERY_NORMAL="ignore"
		POWERSAVE_EVENT_BATTERY_WARNING="notify"
		POWERSAVE_EVENT_BATTERY_LOW="notify"
		POWERSAVE_EVENT_BATTERY_CRITICAL="suspend"
	For extended options for these variables have a look into the config
	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.


    2_1_3) ADJUSTED POWER CONSUMPTION FOR WORKING ON AC/BATTERY POWER

	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.conf set:
		acadapter.online=/usr/sbin/powersave_proxy
		acadapter.offline=/usr/sbin/powersave_proxy
	to let the powersave_proxy handle AC adapter events.

	In /etc/sysconfig/powermanage/common set the scheme that should be
	used:
		POWERSAVE_AC_SCHEME="performance"
		POWERSAVE_BATTERY_SCHEME="powersave"
	The schemes are config files in /etc/sysconfig/powermange. 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) or modify them with the YaST2 Powermanagement module.

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

  *2_2) ADDITIONAL ACPI FEATURES*

	If you are working on ACPI you can customize the behaviour of your ACPI
	buttons. These are: the Power and Sleep buttons and the Lid open/close
	"buttons". Be sure in /etc/powersave.conf is executable set that
	should be executed:
		button.sleep=/usr/sbin/powersave_proxy
		button.power=/usr/sbin/powersave_proxy
		button.lid.open=/usr/sbin/powersave_proxy
		button.lid.closed=/usr/sbin/powersave_proxy
			
	If the events are set to the powersave_proxy (default) you can
	additionally set following following variables to influence what should
	happen when the buttons are pressed:

		POWERSAVE_EVENT_BUTTON_POWER="wm_shutdown"
		POWERSAVE_EVENT_BUTTON_SLEEP="suspend"
		POWERSAVE_EVENT_BUTTON_LID_OPEN="ignore"
		POWERSAVE_EVENT_BUTTON_LID_CLOSED="screen_saver"
	See the config file /etc/sysconfig/powermanage/common for details.

	You can additionally throttle the CPU if e.g. the usage of your CPU
	stays below a certain level (POWERSAVED_CPU_LOW_LIMIT=25 variable in
	/etc/sysconfig/powermanage/common) for a specific time
	(POWERSAVED_CPU_IDLE_TIMEOUT=10000 in ms, same file).

	Other ACPI features like thermal management, etc. are planned.


  *2_3) CPU FREQUENCY SCALING*

	The algorithm for CPU frequency scaling is taken over from Carl
	Thompsons CPUSPEED package  (http://carlthompson.net/software/cpuspeed).
	You can set three modes:
		- performance 	always highest CPU frequence (makes sense for on AC power)
		- powersave   	always lowest CPU frequence  (makes sense if on battery and the 
				lowest supported value is not too low)
		- dynamic 	adjusts the CPU frequence according to the current CPU load
				(this should be the preferred choice for AC and battery power, for low
				temperature and noise (fan) and good performance)

	See 2_1_3 how to let the machine be automatically set on different
	values if you are working on battery or on AC power.
	You can temperarily (until the next time AC/battery is
	plugged/unplugged) influence the policy with the binary:

		powersave --performance-speed, powersave --powersave-speed, powersave --dynamic-speed
		and powersave -c shows the current policy.


_3) HOW IT WORKS, GENERAL DESCRIPTION_

  *3_1)  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 the CPU load to adjust the CPU
	frequency dynamically (if dynamic CPU freq policy is set).
			
			
	_GENERATING EVENTS_
		There are a fixed amount of events that the daemon my throw.
		The events could be generated from the underlying
		hardware/kernel and the daemon just forwards them (e.g. ACPI
		button pressed) or the daemon can generate his own events (e.g.
		low/high CPU usage).

		You could specify an executable that should be invoked if such
		an event happens in the /etc/powersave.conf file.
		By default the happening event is given as paramater. But this
		could also be deactivated (see config file for details).

		These are all possible events the daemon could generate and
		other programs (by default the powersave_proxy) could react on.
		Most of them are self-explanatory, the more complicated are
		explained in detail below:

			daemon.start
			daemon.terminate

			acadapter.online
			acadapter.offline
 
			battery.normal
			battery.warning
			battery.low
			battery.critical
	
			button.sleep
			button.power
			button.lid.open
			button.lid.closed

			global.suspend
			global.standby
			global.resume.suspend
			global.resume.standby
		
			processor.performance
			processor.powersave
			processor.dynamic
			processor.dynamic.high
			processor.dynamic.low

			
		battery.* events are only thrown when switching from a state
		  with more capacity into a state with less capacity (power is
		  drained) therefore theoretically the battery.normal event
		  could never be thrown.

		button.* events are only ACPI related and do not exist/will
		  never be thrown on APM machines.

		global.suspend/standby events are generated if a user requests
		  a suspend/standby using the user binary (powersave --suspend,
		  powersave --standby) or the APM-BIOS requests a
		  suspend/standby (closing Lid, sleep, power buttons on most
		  APM machines). On ACPI machines you can override the
		  behaviour of your buttons and trigger a suspend with the user
		  binary (best use the powersave_proxy, see 2_2).  The daemon
		  then waits until the specified executable finishes (be
		  careful: if it does not end you will never get a
		  standby/suspend, this could easily happen if you (or the
		  powersave_proxy) tries to unload buggy modules ...  As soon
		  as the executable finishes, the daemon triggers the
		  suspend/standby (echo x >/proc/acpi/sleep, or ioctl on APM
		  systems)

		global.resume.suspend/standby are generated when the machine is
		  back from  a suspend/standby and unloaded modules can be
		  loaded or stopped services could be started again (see 2_1).

		processor events are a bit confusing:
		The processor.performance, processor.powersave,
		processor.dynamic are generated as soon as the user changes the
		CPU frequency policy using the user binary (powersave
		--performance-speed, ...).

		If the policy is set to dynamic a processor.dynamic.low event
		is thrown if the CPU load stays below the
		POWERSAVED_CPU_LOW_LIMIT (default 25%) for a specific time
		(POWERSAVED_CPU_IDLE_TIMEOUT, default 10000ms).  This is mainly
		thought to additionally low CPU performance, e.g.  throttling
		if the user doesn't use the CPU.

		As soon as the CPU usage exceeds the POWERSAVED_CPU_HIGH_LIMIT
		(default 75%) once, a processor.dynamic.high event is thrown
		(thought to undo CPU throttling or similar that have been set).
		Now the daemon waits for low CPU usage and exceeding the
		timeout (as described above) until a processor.dynamic.low is
		generated again.
		
		Have a closer look to the files which configure the
		daemon (/etc/powersave.conf and
		/etc/sysconfig/powermanage/powersave).


  *3_2)  PROXY*
			
	The job of the proxy (/usr/sbin/powersave_proxy) is to process events
	that have been generated by the daemon according to the configurations
	in /etc/sysconfig/powermanage/common and
	/etc/sysconfig/powermanage/scheme* (AC/battery related).
	Therefore the proxy should be (and is by default) set to get invoked if
	a event happens. You do that in /etc/powersave.conf, the event
	configuration file for the daemon.

	When an event is generated by the daemon the proxy is now invoked and
	the event is given as a parameter (see 3_1).  You can specify which
	function(s) of the proxy should be invoked for each event. You do this
	by setting the event related variables in
	/etc/sysconfig/powermanage/common to the function(s) that should get
	invoked:
	e.g. button.sleep is related to the POWERSAVE_BUTTON_SLEEP variable.
	Setting POWERSAVE_BUTTON_SLEEP="notify suspend" will cause the proxy to
	process its notify and then its suspend function as soon as the daemon
	generates a button.sleep event.
	This mechanism is a bit complex, but very flexible. Have a look into
	the /etc/sysconfig/powermanage/common file for better understanding.

	Some functions in the powersave_proxy are explicitly written for
	specific events and should not be assigned to others:

		prepare_suspend()  -> should only be invoked if global.suspend event happens
		prepare_standby()  -> should only be invoked if global.standby event happens	
				
		restore_after_suspend() -> should be invoked after global.resume.suspend
		restore_after_standby() -> should be invoked after global.resume.standby
				
	You may write your own function in the powersave_proxy and let it be
	invoked if a event happens:

		in /usr/sbin/powersave_proxy:

			myFunction() { ... }

		in /etc/sysconfig/powermanage/common:

			POWERSAVE_BUTTON_SLEEP="notify myFunction suspend"

			will first invoke the notify function, then myFunction
			and then the suspend function in the powersave_proxy if
			you press the sleep button (and have ACPI supported and
			the default settings in /etc/powersave.conf)

	You should not invoke bigger applications that do not finish for a
	longer time, because the process is still bound to the daemon. Also
	remember that the functions are processed under root/superuser. Do not
	invoke any scripts/binaries that are modifiable by common users, or
	they will gain superuser rights easily!

			

  *3_3) THE USER BINARY*

	This binary (/usr/bin/powersave) provides general information about
	your system (APM/ACPI, battery, throttling, ...).
			
	For some functionalities you may need a running daemon. The binary
	connects to the daemon through a socket and sends its requests (e.g.
	suspend, standby, change CPU freq policy ...)

	For some you need superuser rights: e.g. change throttling of CPU, ...
			
	Keep in mind that the modifications could be only temporarily. They
	could be overridden by the policy of the daemon (e.g. if you plug/unplug
	AC adapter).
			
	The binary should mainly give you some information of your hardware.
	See the manpage (man powersave) for details.


  *3_4) THE LIBRARY*

	If you intend to write your own power manageing program you can make
	use of the provided libraries.

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

	The libpowersave_daemon.a/libpowersave_daemon.so library needs a
	running powersave daemon. It connects to the daemon through a socket,
	sends a request (e.g. suspend, ..., see powersave_daemonlib.h for
	details).


_4) KERNEL CONFIGURATION_

	On current SUSE kernels the settings in the kernel are optimised and
	should work fine with this tool.

	For other distros or kernel hackers:
	
  *4_1) CPU FREQUENCY*

	have a look into the kernel documentation:
		/usr/src/linux/Documentation/cpu-freq/*

	2.6.x kernels:

	  be sure that you have at least following options set like this in
	  /usr/src/linux/.config:

		CONFIG_CPU_FREQ=y
		CONFIG_CPU_FREQ_PROC_INTF=y
		CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
		CONFIG_CPU_FREQ_GOV_POWERSAVE=m
		CONFIG_CPU_FREQ_GOV_USERSPACE=m
		# CONFIG_CPU_FREQ_24_API is not set
		CONFIG_CPU_FREQ_TABLE=m

		# these do not really matter:
		CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
		# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set

		and of course you have to compile at least your specific
		CPUFreq processor driver as a module (e.g.:
		CONFIG_X86_SPEEDSTEP_CENTRINO=m or CONFIG_X86_POWERNOW_K8=m)
		Just compile all drivers as modules and you can't do anything
		wrong!

	On 2.4.x kernels:

		CONFIG_CPU_FREQ=y
		CONFIG_CPU_FREQ_TABLE=y
		CONFIG_CPU_FREQ_PROC_INTF=y

		CONFIG_CPU_FREQ_GOV_USERSPACE=y
		# Be careful, this setting is different!:
		CONFIG_CPU_FREQ_24_API=y

		and your CPU freq processor driver ...

  *4_2) ACPI SUPPORT*

	You should at least have following compiled into your kernel if you
	want to make use of your ACPI subsystem (works fine on my system, feel
	free to fiddle around with hw specifc modules such as the asus or
	toshiba module and tell me about possible enhancements):
		
	Be aware that ACPI_DEBUG is nice to find ACPI errors. But you should be
	familar with ACPI code in the kernel. This setting enormously decreases
	the performance of your system and is only for error finding!
		
		CONFIG_ACPI=y
		CONFIG_ACPI_BOOT=y
		CONFIG_ACPI_INTERPRETER=y
		CONFIG_ACPI_SLEEP=y
		CONFIG_ACPI_SLEEP_PROC_FS=y
		CONFIG_ACPI_AC=m
		CONFIG_ACPI_BATTERY=m
		CONFIG_ACPI_BUTTON=m
		CONFIG_ACPI_FAN=m
		CONFIG_ACPI_PROCESSOR=m
		CONFIG_ACPI_THERMAL=m
		CONFIG_ACPI_TOSHIBA=m
		# CONFIG_ACPI_DEBUG is not set
		CONFIG_ACPI_BUS=y
		CONFIG_ACPI_EC=y
		CONFIG_ACPI_POWER=y
		CONFIG_ACPI_PCI=y
		CONFIG_ACPI_SYSTEM=y
		CONFIG_ACPI_RELAXED_AML=y
		CONFIG_ACPI_INITRD=y	


  *4_3) APM SUPPORT*

	This settings are tested and should be fine:

		CONFIG_APM=y
		# CONFIG_APM_IGNORE_USER_SUSPEND is not set
		CONFIG_APM_DO_ENABLE=y
		# CONFIG_APM_CPU_IDLE is not set
		CONFIG_APM_DISPLAY_BLANK=y
		# CONFIG_APM_RTC_IS_GMT is not set
		CONFIG_APM_ALLOW_INTS=y
		# CONFIG_APM_REAL_MODE_POWER_OFF is not set

	


_5) FAQ, WORKAROUNDS FOR BUGGY HARDWARE_

	First, please be sure the problem is not related to wrong kernel
	configurations (see 4).

	Something wents 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/powermanage/common and restart the powersave
		service/daemon to isolate the error. Messages are again logged
		to /var/log/messages.

	I have ACPI enabled but buttons or/and battery states do not work as
	wanted:
	or
	I have ACPI Errors in dmesg and /var/log/messages:
		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 please visit following sites to find new
		DSDT and override a possibly broken DSDT table of your bios:

		Kernel patch (not needed if you use SUSE 9.0 or higher):
		  http://gaugusch.at/kernel.shtml (patch is already in current
		  SUSE kernels(9.x), see mkinitrd and /etc/sysconfig/kernel how
		  to apply a customized DSDT (from site below or compiled by
		  yourself))
		

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

		For SUSE users (9.0 or higher):
	
		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.


	CPU frequency does not work:
		See in the kernel source if your processor is supported:
		/usr/src/linux/Documentation/cpu-freq/*
		and if you need a special module or module option. If you need
		a special module/option use following variables:
			POWERSAVE_CPUFREQD_MODULE=""
			POWERSAVE_CPUFREQD_MODULE_OPTS=""
		in the /etc/sysconfig/powermanage/common config file to set
		them.

	
	Suspend/Standby does not work:
		
		Suspend (S4):
		
		  On ACPI systems:
		  Update kernel to at least 2.6.0.
		  Remember: Kernel implementation may still not work on your
		  system, because it is outlined as experimental.

		For the more experienced:
		  At that moment there are several kernel patches that support
		  suspend/standby:

		Following problems (kernel related) are known:

		  - you have more than 1GB RAM -> suspend not supported at the
		    moment

		  - you have multiple processors or a P4 (supporting
		    Hyperthreading). Currently not supported (this may already
		    have been changed, search for kernel updates).
		
		Maybe you have a buggy DSDT (BIOS) implementation, see above to
		get a new one (I have ACPI enabled but buttons or/and battery
		states do not work as wanted).


		On ACPI and APM systems:

		  You try to unload modules buggy modules. The proxy hangs and
		  the suspend is never triggered.
			
		  Or the other way around:
		  You do not unload modules/stop services that are critical
		  when loaded and doing a suspend.
		  In both cases:
		    Fiddle around with following configurations in
		    /etc/sysconfig/powermanage/common:

			POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND="uhci_hcd ohci_hcd ehci_hcd raw1394 ohci1394 ieee1394"
			POWERSAVE_UNLOAD_MODULES_BEFORE_STANDBY="uhci_hcd ohci_hcd ehci_hcd raw1394 ohci1394 ieee1394"

			POWERSAVE_SUSPEND_RESTART_SERVICES="pcmcia hotplug"
			POWERSAVE_STANDBY_RESTART_SERVICES="pcmcia hotplug"

		    to find out modules/services that could make problems.
		    Following other modules are known to cause problems and
		    should be unloaded/loaded: "ndiswrapper", "LinuxAnt" and
		    probably a lot more, depending on kernel/driver version.

	      Standby, Suspend to RAM (S3) - ACPI related:

		    The S3 state is even more experimental than S4.  First it
		    is more hardware dependent, because initialisation of most
		    devices is done through the operating system, not the BIOS.
			
		    On a lot of machines the screen will stay black, even the
		    machine seems still to be active (you can try by blindly
		    executing some sounds, or similar).

		    Hopefully this will be fixed soon. For any other bugs or
		    solutions (also kernel related) I'd happy to hear from you.


	My screen is somehow displaced after resuming from standby/suspend:

		There is a function to switch to terminal 1 and back to 7.
		This should normally help.  Modify the event variables for
		resume in /etc/sysconfig/common like that:

		initial values:
		POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND="restore_after_suspend"
		POWERSAVE_EVENT_GLOBAL_RESUME_STANDBY="restore_after_standby"

		to:
		POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND="restore_after_suspend vt_screen"
		POWERSAVE_EVENT_GLOBAL_RESUME_STANDBY="restore_after_standby vt_screen"


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

		As older a battery as worse the remaining capacity.  But it may
 		still work suitable, only the values delivered to the OS may be
 		wrong.
  
  		Try:
 		1) 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).
  	
 		2) 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
 		    often helps.
  
  
 	My battery shows totally weird values, therefore power management is
 	going crazy :
  
  		See section above.

	Lifetime is shorter in comparison to Windows

 		1) Some hardware features could not be supported because your
 		    DSDT does not fulfil the ACPI specification.
  		
 		    Most important feature, see: /proc/acpi/processor/.../power
 		    Your machine must at least support C1 performance state.
 		    If not, see /var/log/messages and theme above: I have ACPI
 		    Errors in dmesg and /var/log/messages:
 
 		2) Is CPU frequency supported by your machine? Does it work
 		    properly?
 		    Try powersave -c. If mode is performance, use the YaST2
 		    powermanagement module or see
 		    /etc/sysconfig/powersave/scheme_* and
 		    /etc/sysconfig/powersave/common to set to dynamic for
 		    working on battery, or best for working on AC and on
 		    battery.
 
 		If CPU frequency scaling is currently not supported, check
 		/usr/src/linux/Documentation/cpu_freq (you need the
 		kernel-source package). Does your processor support this
 		feature? Are special modules or module options needed?  Ajust
 		module settings in /etc/sysconfig/powersave/common if you have
 		an extraordinary processor.
  	
 		Try powersave -r (only works on i686 on x86 based
 		architectures).  If CPU frequency is suppported, and powersave
 		-c returns POWERSAVE or DYNAMIC and your CPU usage is not very
 		high, you should see a value that is much lower than your
 		maximum CPU frequency. If not you found a bug (see email at the
 		beginning to post)
 

	My processor does not run with maximum CPU frequency

 		This is a feature, not a bug. See man powersave how you can
 		measure your exact CPU frequency.  See YaST and
 		/etc/sysconfig/powersave configuration to adjust settings to
 		your needs.



	My system runs very slow

 		Do powersave -c. If POWERSAVE is returned your CPU always runs
 		on lowest frequency.  This could of course have totally other
 		reasons. Check your system (top, ps, ...).
 		
 		Have a look in /proc/acpi/processor/*/throttling. If the state
 		is still not T0 if your CPU load is increases disable
 		throttling in through the YaST2 power management module or do
 		it directly in /etc/sysconfig/powersave/common.
  		
		
	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?
  		
 		Is the powersave daemon running and the file
 		/var/run/powersave_socket does exist?
  		If not restart the daemon: /etc/init.d/powersave restart
  
 		Be sure the powersave group has been added successfully in
 		/etc/group, if not use groupadd powersave (from pwdutils rpm) to add
 		it.
  
 		Add all users you want to allow to access these functions to
 		the powersave group.


	The texts in my terminals are written slowly, my whole system works slow

		Your CPU is probably throttled.
		This could be a feature when you work on battery and CPU usage is slow your CPU
		gets throttled.
		
		Use the YaST Power Management module to deactivate throttling in your schemes
		or directly modify the your scheme files in /etc/sysconfig/powersave/scheme_*

		you could dethrottle your system manually by
		echo 0 >/proc/acpi/processor/*/throttling 

_6) Bugs_

 	- socket file in /tmp, could be deleted and common users cannot connect
 	  to the daemon any more
	
	- calculating frequency could be wrong if processor is in higher 
	  power save (C-)states (C3 and above normally). This is normal.
	

_7) ToDo_

	See ToDo file
	



