[systemd-devel] [PATCH 0/6] Add 'lock' action for hardware buttons

[Ben Boeckel]

On Sun, Oct 28, 2012 at 12:29:36 +0100, Lennart Poettering wrote:
> On Sat, 27.10.12 03:08, Ben Boeckel (mathstuf at gmail.com) wrote:
> > I was surprised to find that my laptops were suspending when the lid was
> > closed after updating to Fedora 18 since I find it a misfeature of power
> > management defaults and it's one of the first things to go on new
> > machines. I much prefer locking the session instead since I leave my
> > machines doing work, but like to also have them be unobtrusive when on
> > my desk.
> > 
> > This series of patches add a 'lock' target which runs `loginctl
> > lock-sessions` and wires it up to a new option for the button. I also
> > added inhibit logic, though this might make less sense at a system
> > level. At the user level, it'd be perfect for media players and the
> > like.
> > 
> > The code hasn't been tested beyond a build and making sure that the new
> > files appear in the install. I have yet to write a simple Python DBus
> > listener to trigger the locker that I use (xlockmore), so I don't
> > (currently) have my setup available to test.
> > 
> > Feedback greatly appreciated.
> 
> So, there's something that confuses me a bit about this: a DE that
> listens to the Lock requests of logind and puts up the screen lock
> should also be capable of taking the key handling inhibitor lock which
> will disable logind's own handling of the key. I mean, if you add logind
> support to your DE you probably should do it fully and go all the way,
> no?

Well, my "DE" is built using parts and pieces (xmonad, xmobar, feh,
keychain, etc.), but once the locking mechanism is put into place,
sticking other logind communication glue in there shouldn't be a big
deal.

> I don't believe we need any special support for inhibiting locks
> though. Inhibiting suspend/poweroff certainly makes a lot of sense,
> since it breaks certain operations. But screen locking doesn't really
> break much.

Yeah, thinking on it again, there's nothing a program can (or, more
correctly, should) do to inhibit locking of the screen if the lid closes
since the screen is ostensibly no longer visible anyways. I imagine that
few will want a 'lock' to be done if the power button is pressed, but I
could see inhibiting *that* if someone set that setting. I suppose if
anyone comes with an actual use for it, then it could be looked at
again, but I don't have anything offhand.

> Anyway, I have now added a minimal patch that introduces "lock", as it
> is really easy to do if we shortcut it internally. I hope this settles
> this anyway, even though the precise use case is not clear to me...

I leave my laptop to do work over the weekend or running an experiment
at work and it's on my desk, so closing it is easy to gain back some
space. Since sleep isn't wanted when the lid closes, not having to
remember to manually lock the session (or wait for the timeout) would be
nice since "I'm going away" can be assumed by the action of closing the
lid.

I wasn't sure of the best way to implement it; piggybacking on the
suspend/hibernate target codepath seemed the way to go; this should be
sufficient for me at least.

Thanks!

--Ben