Once upon a time there were three inhibit API’s:
- HAL: system-wide locks on suspend, hibernate and shutdown
- gnome-power-manager: session inhibit for idle suspend and hibernate
- gnome-screensaver: session inhibit for screen blanking and DPMS
Obviously, this has a few big flaws:
- An application might have to inhibit three services, using slightly different methods
- gnome-screensaver has to expose lots of low level icky stuff for g-p-m to consume
- We’ve got a screensaver doing idle detection
- We’ve got gnome-power-manager writing into gnome-screensaver GConf keys to get the timeouts correct
- It’s not possible to prevent logout or user switching
- The hand-off between the session and power manager is poorly defined, so we get stupid libnotify popups rather than nice dialogue integration.
- We don’t integrate with presence services, so we just ignore away/busy/idle status.
Basically, we need the session manager to take care of the all registrations and handle the interactions. Luckily, this is what Jon McCann has done in gnome-session.
These new interfaces are session management done right. Of course, this breaks the old world order of inhibiting gnome-power-manager and gnome-screensaver. For the 2-26 series all inhibits are proxied by g-p-m and g-s to gnome-session, so everything should pretty much just work like before. But, early in the 2-27 cycle we’re going to remove this compat code and everything will have to go through gnome-session. For most code it’ll just be a couple of lines changed and behind the scenes it’s a much simpler and more powerful design.
Like some of the other changes we are making at the moment (DeviceKit, PulseAudio, KMS) this is a new way of doing things, and things might temporarily break. They’ll be regressions, but things can be fixed quickly and most importantly, correctly. What we were using before just wasn’t good enough. With this new framework, we can do it right for GNOME 3.0.
Nice work!
Will there ever be a possibility to inhibit just one screen? Say prevent the screensaver from blanking a monitor with important stats displayed or the one with a movie playing.
Don’t worry, as long as you don’t break youtube people are unlikely to go mental.
Patrys: at the moment no. But given we now pass the window XID to the session manager, this sort of thing is now possible.
Will the session manager now have the concept of the session being idle (e.g. for changing your presence in applications like Empathy)?
@Davyd: yes, although I don’t think stuff like Empathy is wired up yet. Should be easy enough to do tho.
Isn’t this a step backwards,given the old HAL interface was desktop-neutral and the new gnome-session one is not?
Corey: HAL still exists, although applications don’t need to use it. Long term HAL is going to be phased out in favour of DeviceKit-* daemons, so it’s not really of massive concern. The old HAL interface was clunky, and it was just not possible to plumb it into the session like we needed to.
By the way, would you read this mail:
http://mail.gnome.org/archives/gnome-power-manager-list/2008-November/msg00004.html
which is about this very problem? I guess now is the time to tackle it.
There’s an old bug about this too:
http://bugzilla.gnome.org/show_bug.cgi?id=499994
Ideally, I think we would need:
– a fd.o standard D-Bus interface for this (we absolutely need to avoid a KDE/GNOME problem with inhibit)
– 3 different inhibit levels that prevent resp. screensaver, automatic suspend, and manual suspend (for CD burning, etc.)
Cheers
What if one doesn’t have an XID at hand?
Right, HAL is going to die. But then why not push this kind of interface into devkit? Or are we going to have another go ’round, where gnome-session proxies to a devkit interface in the future when that is more settled?
@hughsie: no Empathy is not wired up yet. If this is landing in GNOME 2.26, I should make it work. It should be straight forward enough.
Out of interest, is the DBus API documented somewhere?
@Davyd: when we’ve done a release of gnome-session with the new code we can upload the generated html somewhere.
@Corey: Well, DK-p is system based, and gnome-session is session based. ConsoleKit is aware of each session, and so I would imagine this goes through ConsoleKit too.
@Snark: pass 0
I don’t quite follow why “It’s not possible to prevent logout or user switching” is a flaw. Is it for cases where, e.g. you’re burning a CD, and if you log out, the burner will get terminated mid-job, resulting in a brand new coaster for your tea cup?
What about user-switches then? Okay, every time I tried to use the fast user switcher applet, my X server promptly crashed, so I can see how it’s the same thing as a logout, but, assuming this gets fixed, what’s the harm?
Thanks — ekiga now supports this (and this closes one of the oldest bugs I had on my TODO…).
From the sounds of it, this change will adversely affect Xubuntu. We use gnome-screensaver and gnome-power-manager to offer user friendly power management options to our users. I’m all for better architect but am I correct in understanding that these changes will make g-p-m and g-s-s depend on gnome session manager? : (
@Cody: Well, no, not really. It does make applications depend on a session process providing org.gnome.SessionManager, but you could code that up in about 50 lines of python if you really wanted.