Bug 499994 - GPM's inhibit semantics are confusing
GPM's inhibit semantics are confusing
Status: RESOLVED FIXED
Product: gnome-power-manager
Classification: Deprecated
Component: general
2.20.x
Other All
: Normal normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-11-27 15:28 UTC by Kai Willadsen
Modified: 2009-03-05 17:48 UTC (History)
4 users (show)

See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments

Description Kai Willadsen 2007-11-27 15:28:42 UTC
Please describe the problem:
In GPM, inhibiting suspend is designed to only be used for situations where you really, really don't want to suspend, such as cases of serious data-loss.

However, inhibit is currently being used to stop my laptop from suspending while it's doing thoroughly unimportant things like playing music (see bug #344979) or streaming files. The appropriate semantics for these activities lies in-between the current inhibit implementation (i.e., let my laptop melt before stopping what you're doing) and screensaver-prodding (i.e., pretend that I'm not idle, even if I am). I'd want the screen to dim and/or blank, and have the laptop shut down if power went critical or I closed the lid, but not otherwise.


Steps to reproduce:
On FC8, start playing a track in Rhythmbox.

Actual results:
Witness 'your laptop will melt if you close the lid' warning.

Expected results:
Have my laptop not suspend when I'm idle if it's playing music, but suspend when I close the lid.

Does this happen every time?
Yes.

Other information:
The inhibit message is scary and not the sort of thing you actually want to ignore, but it's incredibly annoying to have it pop up whenever I start playing songs. Also, see bug #489380.
Comment 1 Bill Nottingham 2008-01-08 20:31:08 UTC
Moreover, it's preventing suspend when the user explicitly requests it via the applet.
Comment 2 Milan Bouchet-Valat 2009-01-11 21:16:54 UTC
I'd like to raise this forgotten bug again.

I think we need an additional D-Bus call for programs that *really* need to prevent the user from suspending the system. This includes burning a CD/DVD, installing packages and a few tasks like that. But the standard inhibit call should merely prevent *automatic* suspend. The user should never be blocked by notifications.

Anyway, the short-term fix is really to allow manual overriding of inhibitions. Please do something, this is a really poor user interaction.
Comment 3 Richard Hughes 2009-03-04 14:46:57 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 4 Milan Bouchet-Valat 2009-03-05 17:48:56 UTC
Richard: how has this been fixed? Will you disable strong inhibiting (i.e. of manual actions) in next release? Thanks!

Note You need to log in before you can comment on or make changes to this bug.