Yesterday, Intel released the PowerTOP utility. It allows to monitor closely the power consumption and to diagnose what software is using the most power.
It requires (at least) a 2.6.21 kernel with /proc/timer_stat (enabled through CONFIG_TIMER_STATS, [commit]).
I've just made this tool available in Mandriva Cooker, in the powertop package. I'm afraid it will unearth some very bad habits from net_applet... (will try as soon as we have a 2.6.21 kernel ready for Cooker)
... or how to find a way to handle ACPI button events in a user-unfriendly desktop
So, we're switching to pm-utils + HAL + gnome-power-manager/kpowersave to do power management. It's great to finally have an unified power management framework, but I'm still not really statisfied with it.
Why? Because I'm not really a desktop-friend, I don't use neither KDE nor Gnome, and I don't use much applets. So, gnome-power-manager and kpowersave are not good options to me.
Furthermore, the ACPI button events are not passed from acpid to HAL, so that these desktop applications can receive. I have to drop the /etc/acpi/events files that used to catch them, or else the events will be handled inconsistently in many ways. So, now, when not in KDE/Gnome, nothing handles these ACPI events anymore, great...
A year ago, the idea of a PolicyManager daemon has been raised, but there has been no implementation for a long time.
It turned out in to PolicyKit and ConsoleKit which will soon be used in a better gnome-power-manager. Though, there is no full integration with power managers yet.
After a discussion between power management application maintainers, an org.freedesktop.Policy.Power interface has been introduced by Novell in kpowersave and powersave. Acquiring this D-Bus interface acts as a lock between power management programs that supports it, so that only one power management policy can get applied. They even patched gnome-power-manager to support this interface.
In Mandriva, to make the events handled when not in KDE/Gnome, I will create a small pm-has-power-policy helper using dbus-send:
dbus-send --system --dest=org.freedesktop.DBus --type=method_call
--print-reply --reply-timeout=200 / org.freedesktop.DBus.NameHasOwner
string:org.freedesktop.Policy.Power
| grep -q 'boolean true'
Then, I have restored /etc/acpi/events helpers, that check if pm-has-power-policy returns false because calling the real actions (poweroff/suspend). Of course, I also have to create a /etc/dbus-1/system.d/policy-power.conf file, to allow user apps to acquire org.freedesktop.Policy.Power.
Finally, I got a simple solution, but the thing is, latest official kpowersave release does not event support poweroff/suspend/hibernate buttons /o\ Yet some more patches to bakport (from kpowersave SVN).
It looks like the better compromise to me as of today, even if the situation will probably evolve quite fast.
Well, what a ride...
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:
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.
That's our suspend-scripts, they work, and we're adding more and more features to it thanks to contributors.
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/
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.
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).
Basically, we can have:
But we miss:
The Linux power management summit might help to get a solution.
