After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
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:
 
 
Reported: 2007-11-27 15:28 UTC by Kai Willadsen
Modified: 2009-03-05 17:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



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!