You are viewing hughsient

Technical Blog of Richard Hughes - gnome-power-manager Inhibit and UnInhibit methods in use

Richard Hughes
Date: 2006-06-14 16:39
Subject: gnome-power-manager Inhibit and UnInhibit methods in use
Security: Public
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:

Post A Comment | 18 Comments | Share | Link



Monument
User: marnanel
Date: 2006-06-14 16:14 (UTC)
Subject: (no subject)
That's excellent!

Maybe "because it is" instead of just "because", because that will make a full sentence.
Reply | Thread | Link



Monument
User: marnanel
Date: 2006-06-14 16:18 (UTC)
Subject: (no subject)
(I am really excited about all this. dbus is opening up so many cool possibilities.)
Reply | Parent | Thread | Link



User: (Anonymous)
Date: 2006-06-14 17:44 (UTC)
Subject: (no subject)
Splicing sentences like that doesn't work well in other languages.
Reply | Parent | Thread | Link



User: federico
Date: 2006-06-14 22:42 (UTC)
Subject: There are pitfalls
Please read http://blogs.msdn.com/oldnewthing/archive/2006/02/16/533250.aspx and the links to which it points. It describes why letting programs override the Suspend command is a bad idea.
Reply | Thread | Link



Richard Hughes
User: hughsient
Date: 2006-06-15 19:11 (UTC)
Subject: Re: There are pitfalls
Yes, I've seem this link and I've considered this. The Inhibit is not a promise that the suspend will be halted, but a recommendation. I can't imagine lots of closed source stuff will start to use this interface, and so OSS we can trivially patch and bugzilla if it uses the method incorrectly.
Reply | Parent | Thread | Link



User: (Anonymous)
Date: 2006-06-14 23:18 (UTC)
Subject: (no subject)
I wanted to make you aware of something in case it effects this.

When the lid on my laptop closes, the system MUST SUSPEND. Otherwise the heat from my CPU, rising thorugh the keys (as designed, the heatsink is under the keyboard), would melt my LCD.

Designed by Apple. =)

However, inhibting suspend when not initiated by the lid close is fine.
Reply | Thread | Link



Richard Hughes
User: hughsient
Date: 2006-06-15 10:07 (UTC)
Subject: (no subject)
>When the lid on my laptop closes, the system MUST SUSPEND.

I'm sure we can work something out with a HAL property or something, so worry not :-)
Reply | Parent | Thread | Link



User: (Anonymous)
Date: 2006-06-15 00:02 (UTC)
Subject: Why?
Why would an app be able to stop suspending? If you're downloading or copying a file, just pause, and continue when you wake up. In fact, I'm not sure I can come up with any good reason to tell me I can't suspend.
Reply | Thread | Link



Danielle
User: dannipenguin
Date: 2006-06-15 00:07 (UTC)
Subject: Re: Why?
Burning a CD would be a good reason. It should at least warn you that you're about to coaster a CD.
Reply | Parent | Thread | Link



Richard Hughes
User: hughsient
Date: 2006-06-15 10:06 (UTC)
Subject: Re: Why?
Image you've got auto-suspend set to 5 minutes of inactivity. You start ripping a CD, which is going to take 20 minutes. You walk away and make a coffee, while it rips.

You come back, move the mouse, and it resumes, after only doing 25% of the rip. Assuming the kernel is in a good mood, the rip continues.

This isn't what the user wants -- g-p-m needs more info from the program about what is happening. This makes things "just work" without having to do dirty blacklists and stuff like that.
Reply | Parent | Thread | Link



User: (Anonymous)
Date: 2006-06-16 06:37 (UTC)
Subject: Re: Why?
"This isn't what the user wants" -- huh? It's exactly what I'd expect.

If you want stuff to run while you're getting coffee, don't set it to suspend after 5 minutes!

If the computer prevents suspend for ripping a CD, then what process *wouldn't* it prevent suspend for?
Reply | Parent | Thread | Link



Richard Hughes
User: hughsient
Date: 2006-06-16 11:11 (UTC)
Subject: Re: Why?
For max power saving, a user shouldn't have to set a policy and then do an action, for the same reason a user shouldn't have to set a "presentation" powersaving policy just before they start a presentation (as lots of research suggests that most people forget to turn it either on beforehand or off afterwards).

This stuff is suppost to just work *with* the user, and not be rigid so that a policy action is done regardless of the users preference.
Reply | Parent | Thread | Link



Danielle
User: dannipenguin
Date: 2006-06-15 00:12 (UTC)
Subject: (no subject)
I like what this is doing. The question is, does it move the machine into an INHIBITED state (instead of leaving it in the running state)? It seems to me that if you close your lid (and you don't have one of those melty LCDs) that it would be handy for your machine to enter the INHIBITED state, and once the inhibitions are gone the machine can enter suspend. If you open the lid again before the inhibitions are gone, the machine will go back to the normal running state.

It would also be quite nice to be able to override any inhibition with a "Suspend Anyway" button, and perhaps have a preference which is "Ignore inhibitions". Actually... that sounds remarkably dodgy.
Reply | Thread | Link



Richard Hughes
User: hughsient
Date: 2006-06-15 10:01 (UTC)
Subject: (no subject)
Good questions. I don't see why if the lid is closed then the computer couldn't do the action when all the inhibited stuff has gone away, but I would need to think more on the state stuff before I started to impliment this.

I was thinking of a [x] ignore inhibit requests in the gui or maybe just a gconf var, to keep people with melty screens happy.

Maybe a "suspend anyway" button might be best as you suggest.
Reply | Parent | Thread | Link



Danielle
User: dannipenguin
Date: 2006-06-15 10:07 (UTC)
Subject: (no subject)
I'm trying to think of a really good use case for the first part, where I am doing an operation and need to quickly shove my laptop in my bag and run for the bus. Perhaps I'm burning a CD. On the bus, I get chatting to the pretty girl next to me, so I forget about the fact that my laptop is still running (or more likely, don't want to get my laptop out and suspend it, because that would be geeky). End result is that my laptop goes flat quicker. I'm also the sort of person who doesn't carry about their plugpack.

'Suspend anyway' works as long as you don't close the lid. I think the best options here are the GConf variable (I can't decide on exposing this to the UI) and the 'Suspend Anyway' button.
Reply | Parent | Thread | Link



prokoudine: just me
User: prokoudine
Date: 2006-06-15 14:30 (UTC)
Subject: (no subject)
Keyword:just me
Great stuff! Very useful for us, laptoppers :)
Reply | Thread | Link



User: (Anonymous)
Date: 2006-06-15 17:25 (UTC)
Subject: Suspend when done
Any chance of having an option to click a button to make the suspend happen once the inhibitions have gone away?
Reply | Thread | Link



Richard Hughes
User: hughsient
Date: 2006-06-15 19:13 (UTC)
Subject: Re: Suspend when done
I think this should be configurable somewhere, at least at the gconf level. I think this makes sense to do this by default if the laptop lid is closed or the computer is idle, but not if the user clicks the tray icon.
Reply | Parent | Thread | Link



browse
my journal
April 2008