[systemd-devel] Handling lid close in logind?

Matthias Clasen mclasen at redhat.com
Tue Sep 18 05:10:14 PDT 2012


On Tue, 2012-09-18 at 00:28 +0200, Lennart Poettering wrote:
> On Mon, 03.09.12 22:10, Matthias Clasen (matthias.clasen at gmail.com) wrote:
> 
> > 
> > On Mon, Sep 3, 2012 at 5:17 AM, Richard Hughes <hughsient at 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. 



More information about the systemd-devel mailing list