[systemd-devel] Handling lid close in logind?

Mantas Mikulėnas grawity at gmail.com
Tue Sep 4 08:37:32 PDT 2012


On Tue, Sep 4, 2012 at 5:10 AM, Matthias Clasen
<matthias.clasen at gmail.com> wrote:
> 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.

This sounds good to me as an user. Most of the time, if I press the
"Suspend" button (be it a real button or the laptop lid), I want it to
suspend right /now/, without any prompts [or the fade-to-black, which
GNOME insists on...]

But at the same time, I /do/ sometimes want to close the lid while
keeping the laptop on (e.g. to carry it somewhere nearby), without
having to wait for it to resume and reconnect to WiFi.

Unfortunately, "HandleLidSwitch=always" ignores all inhibitors. (I
cannot use other values than "always" because I often play around with
various DEs and WMs that simply don't have their own lid-close
handlers, while logind is always present.)

Also, my laptop's battery is a bit broken and the reported capacity
often jumps from ~30% straight to 0%. When that happens, UPower
immediately tries to hibernate the system, even though I have more
than enough time to just find the charger. Because of this, it would
be very useful if I could inhibit even root-initiated (or at least,
UPower-initiated) hibernation, since normal inhibitors are overridden
by root.

Maybe there should be two inhibitor classes? – "application" or
"normal" (overridable by root command, hardware events, &c.) vs "user"
or "forced" (cannot be overridden even by lid close nor battery
emergency)... ["application" would remain the default for all existing
interfaces, though]

-- 
Mantas Mikulėnas


More information about the systemd-devel mailing list