On Tue, 2012-09-18 at 00:28 +0200, Lennart Poettering wrote: > On Mon, 03.09.12 22:10, Matthias Clasen (matthias.cla...@gmail.com) wrote: > > > > > On Mon, Sep 3, 2012 at 5:17 AM, Richard Hughes <hughsi...@gmail.com> 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.
The think thats missing here is that 'click Suspend in menu' and 'close the lid' are really quite different, in terms of how we need to handle them. The first is a user action that can be handled with inhibitors just fine - we'll show the dialog, the user makes an informed decision, no harm. The second is a hardware event (admittedly triggered by user action), we really have no choice but to react to it. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel