What's Chris been doing?

I’ve been thinking about and exploring possible solutions to the problem I mentioned in my last post.

The more I read about DBus, Gnome and HAL the more I realise that I should be working with them rather than subverting them with lcfg-sleep. They detect the idleness of a user’s X session far more easily than I can, they have sophisticated tie-ins with other software via DBus (a common example is that a DVD player application can ask the screensaver to refrain from screen-saving while a film is playing), and gnome-power-manager has facilities I could use for setting default (overridden by user preferences) and mandatory (overrides user preferences) behaviour in matters such as automatically suspending a machine after the session has become idle. They also support use of the same display quirks which I’ve had to use with lcfg-sleep to get displays up and running again at resume time – and today I’ve tried enabling quirks in HAL then suspending with Gnome’s suspend method and they work, they bring the display back to a working state after resume, which isn’t what happens when the right quirk is not enabled.

Anyway, enough about quirks and stuff; the main idea is this. When it runs lcfg-sleep should detect whether or not there’s a user X session, and if there is, lcfg-sleep will refrain from suspending the machine. Instead it’ll back off to fallback behaviour of just calculating a suitable wake time for the machine and writing that to the kernel wake time file. Gnome-power-manager can be trusted to do the idleness detection and suspension. We can set default preferences for it to suspend the machine a suitable number of minutes after it judges the session to have become idle. Resume will happen thanks to the wake time which lcfg-sleep will have written to the kernel alarm file before suspend. lcfg-sleep doesn’t get triggered by gnome-power-manager or anything, it just runs regularly, every minute or two, and writes a suitable time to the kernel alarm file every time it runs; so there should always be a correct wake time (for example, in the future rather than the past) in the kernel alarm file. I’ve tested using gnome-power-manager’s suspension in conjunction with lcfg-sleep’s waketime and it works. (Well, it works as long as you set the proper display quirks in a HAL quirk database file anyway.)

When there’s no user X session detected, lcfg-sleep can revert to its fuller behaviour of triggering suspend as well as setting wakeup time.

We could even perhaps base relevant gnome-power-manager default values on similar lcfg-sleep resource values. The gnome default values are set using gconf, and James has a handy lcfg-gconf component in the repository…

As you may know I’ve been working on the lcfg-sleep component.
It’s in a testing phase at the moment. I had thought that development work on it had finished, and that the main thing still to sort out was various OS bugs. However Tim has been trying it out and has encountered a problem I hadn’t – in retrospect I suppose this unsurprising as I’d just been using it on remote machines, whereas Tim tried it out on his main work desktop!

What he found was that the idle detection was inadequate. He’d be sitting there happily editing a document with a text editor and the machine would go to sleep on him. Currently the component checks to see that all interactive login shells have an idle time of more than a specified duration (our default is 10 minutes) and that all three load average figures are below a certain level (I’ve set it to 0.1). A machine whose user is just doing light text editing can easily fulfil both of these criteria. A text editor running in the terminal window updates the interactive shell’s idle time, but one running in a separate window of its own doesn’t.

Something needs to be added. After casting about for some method of checking for keyboard or mouse activity I’ve been thinking of checking the Gnome Screensaver status – it can tell you whether the session is currently idle or not, for instance. This turns out to be doable via DBus, the interprocess communication bus used by Gnome and (in the next major version) by KDE. For instance I can use DBus to simply ask the screensaver whether it currently considers the session to be idle or not. Great. Gnome is the default at our site so hopefully we’d still get a big win on our electricity bill even if we refused to sleep on machines with a current X session ongoing but which weren’t running Gnome.

There’s a problem though. DBus has more than one bus: the machine has one system bus and each user login session has its own session bus. Gnome Screensaver uses the session bus. You can therefore talk to the screensaver from a process in the same session, but it seems that you can’t from a process which isn’t part of that session – like an LCFG component. So how to get the information (whether or not the screensaver considers the session idle) to the LCFG component?

Here is the (unstable!) Gnome Screensaver DBus API, and here‘s the homepage.

Presumably you could (somehow) get every user session to run a wee process which queried gnome screensaver, or looked for “idle” announcements for it, then (say) wrote the current status to a file somewhere; but it all sounds terribly yucky and fraught with problems.