[systemd-devel] Lid close event delivered delayed

[Andrey Borzenkov]

В 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

> Or are you saying that you had an X session running which took the lock,
> then closed and reopened the lid, and when you then switched to a VT the
> machine was suspended?
>