Richard Hughes ([info]hughsient) wrote,

gnome-power-manager Inhibit and UnInhibit methods in use

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 new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    Your reply will be screened

    Your IP address will be recorded 

  • 18 comments

[info]marnanel

June 14 2006, 16:14:39 UTC 5 years ago

That's excellent!

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

[info]marnanel

June 14 2006, 16:18:49 UTC 5 years ago

(I am really excited about all this. dbus is opening up so many cool possibilities.)

Anonymous

June 14 2006, 17:44:51 UTC 5 years ago

Splicing sentences like that doesn't work well in other languages.

[info]federico

June 14 2006, 22:42:10 UTC 5 years ago

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.

[info]hughsient

June 15 2006, 19:11:31 UTC 5 years ago

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.

Anonymous

June 14 2006, 23:18:30 UTC 5 years ago

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.

[info]hughsient

June 15 2006, 10:07:42 UTC 5 years ago

>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 :-)

Anonymous

June 15 2006, 00:02:48 UTC 5 years ago

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.

[info]dannipenguin

June 15 2006, 00:07:19 UTC 5 years ago

Re: Why?

Burning a CD would be a good reason. It should at least warn you that you're about to coaster a CD.

[info]hughsient

June 15 2006, 10:06:52 UTC 5 years ago

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.

Anonymous

June 16 2006, 06:37:58 UTC 5 years ago

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?

[info]hughsient

June 16 2006, 11:11:52 UTC 5 years ago

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.

[info]dannipenguin

June 15 2006, 00:12:32 UTC 5 years ago

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.

[info]hughsient

June 15 2006, 10:01:02 UTC 5 years ago

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.

[info]dannipenguin

June 15 2006, 10:07:04 UTC 5 years ago

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.

[info]prokoudine

June 15 2006, 14:30:20 UTC 5 years ago

Great stuff! Very useful for us, laptoppers :)

Anonymous

June 15 2006, 17:25:20 UTC 5 years ago

Suspend when done

Any chance of having an option to click a button to make the suspend happen once the inhibitions have gone away?

[info]hughsient

June 15 2006, 19:13:33 UTC 5 years ago

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.
Create an Account
Forgot your login or password?
Facebook Twitter More login options
English • Español • Deutsch • Русский…