GNOME Bugzilla – Bug 499994
GPM's inhibit semantics are confusing
Last modified: 2009-03-05 17:48:56 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.
Moreover, it's preventing suspend when the user explicitly requests it via the applet.
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.
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.
Richard: how has this been fixed? Will you disable strong inhibiting (i.e. of manual actions) in next release? Thanks!