[systemd-devel] [RFC] logind lid switch inhibitors

[Lennart Poettering]

Heya,

Currently, logind expects that the DE in the foreground handles the lid
switch, the sleep and power keys of the machine. The idea was that the
DE would handle the key presses on its own and then issue the right
action to logind on the user's behalf. 

There turned out to be two problems with this approach:

- The GNOME folks believe that the user clicking on "suspend" in the
  menu and the user closing the lid switch should be two different
  things. The former should honour inhibitors, possibly showing a dialog
  to override them (of privs are available). In the latter case the
  suspend should happen, in any case, ignoring all inhibits. Currently
  the latter logic is not supported with logind.

- People who use minimal DEs wo do not handle power/sleep/lid switch key
  events do not get handling of these keys and still end up installing
  acpid to make the keys work.

We'd now like to propose the following new logic to deal with both these
issues:

- logind from now on handles lid switch/suspend key/power key in all
  cases, even if a graphical DE is running. In fact, any special handling
  of graphical DEs in logind is removed entirely.

- If a desktop wants to intercept some of the keys it needs to take a
  new inhibitor of types INHIBIT_POWER_KEY_HANDLE,
  INHIBIT_SLEEP_KEY_HANDLE and INHIBIT_LID_SWITCH_HANDLE. If an inhibit
  of this kind is taken logind won't handle the respective events.

- If GNOME wants to handle power key/sleep key on its own it would just
  take the two inhinbitor locks for that and be on its own

- If GNOME detects that a second screen is plugged in and wants to
  ensure that in such a case a closed lid should not result in system
  suspend it also takes appropriate INHIBIT_LID_SWITCH_HANDLE for it.

- DEs which cannot handle any of the three events don't have to do
  anything, as logind will do all handling for them.

We think this would solve the two issues nicely, would allow us to
remove special magic for graphical logins and would be quite secure,
since we don't have to allow sessions to override suspend inhibitors at
free will. Only logind itself can choose to ignore inhibitor locks,
nobody else.

Comments, suggestions?

If everybody is happy I'll hack this up tomorrow, and this should hit
F18 within the week.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.