[systemd-devel] Lid close event delivered delayed

[Lennart Poettering]

On Fri, 26.04.13 10:17, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> 'Twas brillig, and Andrey Borzenkov at 17/04/13 18:01 did gyre and gimble:
> > В Wed, 17 Apr 2013 17:31:14 +0200
> > Lennart Poettering <lennart at poettering.net> пишет:
> > 
> >> On Wed, 17.04.13 17:20, Jan Engelhardt (jengelh at inai.de) wrote:
> >>
> >>>
> >>>
> >>> On Wednesday 2013-04-17 16:42, Lennart Poettering wrote:
> >>>> On Wed, 17.04.13 06:58, Jan Engelhardt (jengelh at inai.de) wrote:
> >>>>
> >>>> Well, the current logic is that we suspend when the lid is
> >>>> closed,[...] Lid switch inhibitor locks are currently per-VT, i.e. a
> >>>> lock taken by GNOME is considered irrelevant if you switch away from
> >>>> GNOME.[...] So in order to make sure the lid switch suspend works
> >>>> fine even when you happen to switch away from GNOME logind will
> >>>> handle it then.
> >>>
> >>> That reasoning is perfectly fine; the problem is that logind
> >>> acts upon a physical lid state change from the distant past.
> >>
> >> Well, it is level-triggered, not edge-triggered. If the lid is closed
> >> and a lock released we immediately act and suspend. That's the only
> >> reliable and safe way to do that.
> >>
> > 
> > One problem is, it breaks existing behavior and quite badly. How users
> > are supposed to start inhibitors on ttyX the very moment they switch to
> > it?
> > 
> > It probably needs to be more compatible with exiting behavior by
> > default.
> > 
> > I remember something very similar recently ... ah, here it is
> > 
> > http://lists.freedesktop.org/archives/systemd-devel/2013-March/009988.html
> 
> Does this mean if:
>  1. I use Gnome.
>  2. I have external monitor attached.
>  3. I close the lid because I don't use my laptops screen, just the
> external one.
>  4. I switch to a VT
>  5. My machine is insta-suspended?

Yupp.

> If so then I concur that it needs handled a bit better!

Well, probably. The question though is how to do this best.

A simple way might be to consider the lid switch different from the
suspend/hibernate buttons. i.e. the lock for the former would be global
the one for the latter would be per-active-session.

However, that might not cut it as there are different reasons why
programs take the lock. Some programs might want to take the lock
because they want to handle the key even themselves (let's call them
type A), others take it because they want to turn off the entire logic
(type B). The latter want a global lock, the former a per-active-session
lock. 

Now the question is what to make of this. One option would be to
duplicate all lock types into the current lock plus a global
counterpart.

Hence, clients of type A would continue to take "handle-lid-switch", but
those of type B would start to take "handle-lid-switch-global" instead.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.