[systemd-devel] [RFC] logind lid switch inhibitors
lennart at poettering.net
Tue Sep 18 10:17:04 PDT 2012
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
- 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,
If everybody is happy I'll hack this up tomorrow, and this should hit
F18 within the week.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel