On Mon, 03.09.12 22:10, Matthias Clasen ([email protected]) wrote: > > On Mon, Sep 3, 2012 at 5:17 AM, Richard Hughes <[email protected]> wrote: > > > I don't think the desktop guys want any kind of authentication when > > the lid is closed. How feasible would it be to do the suspend when the > > inhibit is removed? I guess then it puts logind into a "active but > > will suspend asap" state which might be difficult to handle. > > As I said on irc, the user experience I envision in this case is: > > - user closes lid > - polkit dialog is shown (not useful because the lid is closed) > - we beep a few times to cause the user to open the lid and see the dialog > - if the lid is not opened, we forcefully suspend after a few seconds > > A similar situation where we can't wait for a policykit dialog to be > answered is emergency shutdown when the battery runs empty.
So, what I wonder is: if this inhibitor is supposed to be ignored, why take it in the first place? I mean, the inhibitor is supposed to inhibit, no? To me it appears really as if the inhibitor should not have been taken in the first place/not have been allowed to be taken in the first place, rather then not being honoured after it was successfully taken. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
