Hi, a short brief/information about the current planed and already started development for the new KPowersave development tree (0.7.x) and the next stable version (0.8.x):
Preamble
======================
Since Powersave starts to die and the powermanagement tasks going into HAL we
need to change KPowersave to use HAL instead of Powersave.
Only for the log: I don't like this step and for me is the concept to put
_all_ (hardware information, powermanagement, mounting, partition,
format ...) stuff into one daemon,
<rant> (into this crappy HAL and only because some desktop developer are
not able to write a UNIX like daemon for special tasks)
</rant>
a really stupid idea.
I liked the old powersave. This was a great piece of code which contains
several man-years of knowledge about ACPI/APM and powermanagement and did a
great job over the years. I'm not happy about losing it.
This changes mean at least also more trouble in KPowersave.
Table of contents:
======================
(1) HAL/Powersave basics
(2) replace Powersave
- suspend2*/standby
- battery alarm states
- CPU Frequency Policy
- schemes
(3) GUI
(4) Testing
(5) Documentation/Translation
(6) Timeframe
(1) HAL/Powersave basics
==========================
Currently KPowersave use Powersave and libpower from powersave to get
hardware information, to switch schemes, to set CPU Freq and to trigger
suspend2*/standby.
In general we need to connect now directly to HAL to get a signal if something
on hardware changed, if we want to avoid permanent polling e.g. for battery
information via libpower. There are two possible ways: listen to HAL for
changes and call libpower to fresh up device information or listen to HAL and
collect all device information directly in KPowersave.
I would go the second way. This should reduce the overhead of the library
(libpower currently (old version KPowersave currently depends on) provide
several info we never need and miss some other info we need now). If we
implement this directly in KPowersave we can cache the information and need
only to update the changed values (e.g. we need only call hal for current
battery percentage and only for this key and only for this special battery)
which should reduce the overhead on DBUS and allow KPowersave a finer grained
signal and information pool.
Needed work:
* implement a new class to:
- hold connection to the HAL interface via DBUS (done)
- to provide a layer to libhal to get device info (done)
- add methods to find devices by capability and property (done)
- to provide a layer to call DBUS methodes on HAL/DBUS interface (done)
* implement a class to collect and abstract:
- battery, ac, lid information (75% done, need to think about the battery
stuff)
- info about suspend, brightness, CPU Freq (done)
--> open TODO: add support for PolicyKit information
and:
- Add function to update the related info if something changed.
(in progress, Danny/Frank)
(2) replace Powersave
==========================
To replace currently by powersave provided functionality we need to change
several issues in KPowersave:
suspend2*/standby:
--------------------
Old Powersave provided a interface to trigger suspend2*/standby and to check
if the user is allowed to call this methodes. HAL provide currently only a
abstraction of the kernel interface, which mean we can only say if the
machine/kernel can suspend in general, but we can't say if
a.) the user is allowed to call these methodes
b.) if the machine is really suspendable (or if the machine is e.g. not able
to suspend2ram and is blacklisted e.g. in s2ram).
WARNING/PROBLEMS:
* I have currently no idea how we can fix this. Maybe via PolicyKit, but this
is not sure because we don't know if this go really in SUSE 10.2 or if
PolicyKit is mandatory for HAL upstrean in the future.
This situation is really bad and the sideeffects are annoying for the user.
* HAL only support suspend2* and not standby atm upstream (on SUSE we have a
patch for this).
battery alarm states:
-----------------------
Powersave currently provide the battery alarm states and the config at which
point which state is reached. We need to move this to KPowersave and make it
configurable only in general and not per scheme. We need to configure the
three states and the related actions (e.g. warn user, suspend, shutdown)
WARNING/PROBLEMS:
* Several different users can be connected to the system and every user can
define different states and different actions which results in a chaos. This
is at least again the same problem as with CPU freq via HAL and fighting
clients.
--> maybe add this to a admin mode dialog as e.g. in KControl and allow
only a systemwide config, but this is only a solution for KDE.
--> evaluate: discussion started by Holger at:
http://thread.gmane.org/gmane.comp.gnome.powermanager.devel/1251/focus=1251
CPU Frequency Policy:
-------------------
Since CPUFreq settings are moved from powersave to HAL, we need also to
replace the current settings in KPowersave. There are two issues:
* make the currently existing different CPUFreq Policies configurable
* make them configurable per scheme
WARNING/PROBLEMS:
* Fighting Clients and other tools (see above).
schemes:
-----------
Powersave currently provide some schemes (powersave, performance, presentation
and acoustic), two of them are automatically switched if the AC plug is
removed/inserted. We need to implement _real_ schemes in KPowersave. We have
currently schemes in KPowersave (with brightness, screensaver, DPMS,
autosuspend settings and so on), but we need to make them configurable. This
mean we need this stuff:
* create new/remove/edit for current schemes
* make configurable default schemes for AC online/offline (and maybe other
events as e.g. lidclose or if detectable adding a beamer to the machine for
presentation scheme)
* per scheme CPU Frequency settings (see above)
* per scheme disk settings
WARNING/PROBLEMS:
* There is currently no way to set the harddisk settings, but we need this on
some machines which change the settings e.g. via the BIOS on suspend or if
the AC plug is removed (which maybe increase Load_Cycle_Count and reduce
liftime of the disk).
* Fighting clients with different settings.
(3) GUI:
==========================
Based on the changes from (2) we need to update the configuration dialog to
make all the settings configureable for the user.
As a first step we don't need to implement this (first finish the basic
stuff), we can do the config via the config file. Tasks to do:
* create/remove schemes, as first new schemes with a default config (first
steps done)
LATER: maybe add a wizard for inexperienced users
* CPU Freq stuff (per scheme, and per policy)
* AC state and actions (global settings)
* Battery states (global settings)
(4) Testing
==========================
Provide first working version as always on sf.net/freshmeat and kde-apps.org,
send a mail to opensuse ML.
(5) Documentation/Translation
==========================
Need to extend, update and translate the documentation. We need also some new
translations.
(6) Timeframe
==========================
A first stable running version - without not needed stuff from (3) - until
openSUSE Beta1/2/final. With the new stable and without dependecy to
powersave we can think about push KPowersave into KDE SVN as default KDE
powermanagent applet.
You can find all already done changes on the KPowersave SVN on trunk.
Feel free to comment and ...
Cheers,
Danny
pgp1OV0puh0QC.pgp
Description: PGP signature
_______________________________________________ powersave-devel mailing list powersave-devel@forge.novell.com http://forge.novell.com/mailman/listinfo/powersave-devel
