There is no "official" backend right now, basically because there is no daemon that can be used by both Gnome and KDE apps. klaptop has its own powersaving handling, and we didn't use anything special on Gnome but the cpufreqd daemon.

An interesting thread on debian-devel: http://lists.debian.org/debian-devel/2005/12/msg00068.html And their powermgmt project: http://powermgmt.alioth.debian.org/dokuwiki/ But as usual, once an interesting solution is proposed, err...

What we need is:

• automatic detection and load of power saving modules at boot
• a set of tools to deal with suspend
• a desktop agnostic frequency scaling daemon
• a generic layer on top system tools
• tools that use the same backend on both Gnome and KDE

Modules detection

The detection of power saving modules is currently done by the cpufreq service. It's not really nice since it really does the detection at each boot. Better move it to drakx/harddrake, so that it runs only when a new CPU is detected, and puts modules in modprobe.preload. That's planned.

Suspend tools

That's our suspend-scripts, they work, and we're adding more and more features to it thanks to contributors.

Frequency scaling daemon

Frequency scaling is better done in a daemon (for consistency between desktops, and systems not using any dekstop).

Then, we have this new powersave daemon, that looks quite Suse oriented. But it's not granular enough IMHO, it mixes frequency scaling and suspend. It will probably conflict with our suspend-scripts, but I haven't really looked at it yet. http://powersave.sourceforge.net/

cpufreqd looks like a good power saving daemon. It offers a dynamic mode, supports multiple profiles, and allow them to be chosen from a command line interface. http://cpufreqd.sourceforge.net/

Generic layer

Now, a generic suspend backend is available in HAL, and we will add suspend-scripts support there (pmsuspend command, patch available on our Bugzilla).

But it doesn't offer anything to control the frequency scaling yet. See these monster trolls: http://thread.gmane.org/gmane.comp.gnome.powermanager.devel/575 http://lists.freedesktop.org/archives/hal/2005-November/003970.html And interesting point of view: http://pbbuttons.berlios.de/wiki/doku.php?id=futurepmgr:futurepmgr

The previous effort was a power manager daemon, but it's now obsoleted by the new HAL layer: http://live.gnome.org/PowerManager HAL also obsoletes pmscripts.

Desktop tools

So, gnome-power-manager looks like a good candidate for Gnome: http://www.gnome.org/projects/gnome-power-manager/

The HAL layer should be the way to go, but unfortunately, I'm not aware of any KDE daemon using this HAL interface to run actions... http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00337.html

kpowersave uses the HAL layer to get hardware information, that's good news and better than I expected. But it directly interacts with powersave when it's about doing suspend or applying scaling policy... So, it may be the default KDE applet, once it fully uses HAL to run actions (which should be quite doable, since HAL supports powersave on Suse).

So?

Basically, we can have:

• drakx/harddrake handling power saving modules detection
• suspend-scripts as suspend tools
• cpufreqd as a frequency scaling daemon
• HAL as an abstraction layer for suspend
• a Gnome applet fully using this layer (gnome-power-manager) and a KDE applet using it partially (kpowersave)

But we miss:

• a generic layer to control frequency scaling
• tools using this hypothetical layer

The Linux power management summit might help to get a solution.