Today 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, (into this crappy HAL and only because some desktop developer are not able to write a UNIX like daemon for special tasks) 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:
- HAL/Powersave basics
- Replace Powersave
- GUI
- Testing
- Documentation/Translation
- 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, TODO: add support for PolicyKit information)
- 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:- the user is allowed to call these methodes
- the machine is really suspendable (or if the machine is e.g. not able to suspend2ram and is blacklisted e.g. in s2ram).
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)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 we 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: g-p-m Mailing list)
- make the currently existing different CPUFreq Policies configurable
- make them configurable per scheme
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
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 lifetime 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 we can 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) TestingProvide first working version as always on sf.net/freshmeat and kde-apps.org, send a mail to opensuse ML.(5) Documentation/TranslationNeed to extend, update and translate the documentation. We need also some new translations.(6) TimeframeA 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 powermanagement applet.You can find all already done changes in the KPowersave SVN at trunk.
