Category: Uncategorized

Further to my earlier posts, I've been improving the documentation for the Inhibit and UnInhibit methods, and really testing them hard. There's now a testing utility, gnome-power-inhibit-test in g-p-m CVS that allows you to play with multiple Inhibits and other issues. The testing utility shows how easy it is to add the DBUS methods into your program. The same methods can be used with GNOME Screensaver (but you'll have to change the service and interface names to ScreenSaver). Trying to suspend when we have an multiple Inhibit requests gives us this. And a single inhibit:

There are now daily CVS dbus rpm's available in the repo.

This is another package that might eat babies, but DBUS should be getting more and more stable as it gets closer to version 1.0.

I've moved the FC5 utopia repo to people.freedesktop.org because I shouldn't really be hosting a yum repo on SourceForge webserver, and because SourceForge is so slow and broken on a daily basis.

If you've been using the utopia experimental cvs daily builds for FC5 (i386 and ppc) then you need to switch you utopia.repo file to a new location.

Code that is being built daily in a semi-automated way is hal, PolicyKit, gnome-screensaver, pm-utils, icon-naming-utils, tango-icon-theme and of course gnome-power-manager.

I can't guarantee that any of this stuff actually works, as this stuff is more bleeding than rawhide, if you can get such a thing.

If stuff breaks, as always, you get to keep both pieces.

Okay, my last post talked about the lowest layer of power-management. To keep people interested, I'll today talk about the highest layer of gnome-power-manager i.e. the DBUS interface.

GNOME Power Manager has a complete API, that has recently been changed to be more in line with DBUS specifications and to better please the XDG guys with the more general method names. Please review and give me feedback.

If you are a developer reading this, then the most important methods to know are Inhibit() and UnInhibit(), which also exist in gnome-screensaver.

Why two identical methods on different service names?

The reason is; If you Inhibit() on org.gnome.ScreenSaver, then the screensaver will not come on (i.e. the session will not become idle) when you are doing an activity. This is obviously most suitable for visual stuff that requires the screen like playing a DVD in totem or doing a presentation in OpenOffice.

If you do an Inhibit() on org.gnome.PowerManager then the session is marked as idle, so the screensaver can go on, but the computer does not auto-suspend or power down when the mouse has not been moved for the timeout period. This is suitable for applications like bittorrent, epiphany (when downloading a big file), and nautilus (when copying a big file from a network share).

Although this seems potentially like modifying lots of programs for little gain, this all makes the software “just work” without having to manually set power profiles (which is bad) or move the mouse to special hot-spots to prevent things happening. This also removes the need for a “blacklist” of applications that inhibit suspend, as this is inherently broken.

It also lets us inform the user if they try to do silly things, like if the user clicks hibernate, and k3b is about to finish writing a DVD, we can ask the user “are you really sure, as K3B is writing a DVD…”

Aaron Whitehouse has been compiling a list of applications that need bugs filed, or should use the Inhibit() interface which I hope you guys can add to.

If you read the spec files for gnome-power-manager and gnome-screensaver you can see that they are designed to be easy to use.

Comments, as usual, appreciated.

As promised, here's the first of five posts about how all the power management will fit together.

Today I'll discuss the lowest layer, pm-utils.

Sometimes we may need to unload modules or sync hardware times on suspend or resume or do certain things to certain hardware (for instance turning on the suspend LED on IBM hardware) and also do vendor specific things. The problem domain seems vast, but the problems are all small and simple if broken down.

There are numerous different admin scripts and side-programs invented by modern distros (such as Redhat pm-utils, Ubuntu acpi-support and SuSe Powersave) but there has not been any standardization between distros or vendors.

This is where pm-utils steps in.

The idea of pm-utils is for really simple scripts to be installed, and then for software and hardware vendors to just install a simple script in a standard location to do something insane.

For instance, vmware could install the vmware suspend script (to suspend a vmware session before we hibernate) into a standard place without having to bodge each distro setup individually. In this way, the smallest distros get the same level of compatibility and integration as the big guys like SuSe and Redhat.

The hooks are placed in /etc/pm/hooks/ and are just simple shell scripts. Scripts are processed in alphabetical order for suspend and hibernate and reverse alphabetical order for resume or thaw. This means they are really very simple to write and most importantly very easy to install.

pm-utils in CVS now looks very different than the original Fedora-only package, and is now a standard module suitable for any distro with all the autotools goodness. It was chosen over the ubuntu scripts as we were familar with the Redhat scripts, they were better structured, and Peter Jones was happy to maintain it externally. pm-utils is changing rapidly, so CVS is the only sane way to review the latest scripts.

As a bonus, pm-utils also provides pm-powersave, allowing us to use the same principle of small manager script, with multiple hooks for powersaving actions. For instance, a vendor could install a led script into /etc/pm/power.d/ so that a light could turn green on a new laptop model when in low power mode. At the moment, only a laptop-mode script is installed, but other scripts will be added with time.

Soon, pm-utils will be a hard dependency of HAL, so we can get rid of all the compatibility scripts in HAL, making everything that little bit more sane.

Hopefully distros will converge to this common solution, converting their custom scripts into sane pm-utils rules.

Email me with questions, or comments.

This is my very first blog entry. I've been asked to write blog entries about gnome-power-manager related stuff, and until now I've politely refused. Look forward to some in-depth discussions about specific details about how all the PolicyKit, HAL, g-p-m, g-s stuff fits together.