[aur-general] Moving xss-lock to community

Alad Wenter alad at mailbox.org
Thu Jan 18 20:18:07 UTC 2018


On Thu, Jan 18, 2018 at 08:52:23PM +0100, Pierre Neidhardt wrote:
> 
> Alad Wenter via aur-general <aur-general at archlinux.org> writes:
> 
> > If you use polkit and acpid, a "simple" alternative is to use
> > systemd-inhibit, and run actions based on acpid events. Not sure there's
> > a ready implementation with X support in mind.
> 
> Could you detail this?  How do you set it up?  What is lacking in terms
> of X support?
> 
As we know, logind by default does actions like suspend on closing the
lid or pressing the suspend button. Rather than modify these actions to
run some event (like locking the screen priorly) through services files,
you can temporarily disable them with systemd-inhibit. [1] Example:

  $ systemd-inhibit --what=handle-lid-switch --why=Locker screenlocker

The default mode is "block", which delays the set actions indefinitely.
To use it as a regular user, you rely on polkit. This is quite similar
what DE power managers à la xfce4-power-manager do.

"screenlocker" in its most basic form would look at ACPI events from
acpid, and run actions accordingly. Example: [2]

  #!/bin/bash
  coproc acpi_listen
  trap 'kill $COPROC_PID' EXIT

  while read -u "${COPROC[0]}" -a event; do
      handler.sh "${event[@]}"
  done

The benefit of this (and xss-lock's) approach is that your screenlocker
program is run in the environment of the current user, so there's no
need for common hacks such as hardcoding DISPLAY. With systemd-inhibit
you also have some fallback in place should "screenlocker" fail for some
reason, at least assuming it exits on error.

Of course, you can extend the scope of "screenlocker" to react to any
arbitrary ACPI events, for example for volume controls - with latter you
get functional controls in full-screen applications as well.

One issue remains and that is how the program should react when you log
out from your X session, that is when the currently running X server
terminates. xss-lock would simply quit in this case, and if writing in C
you should be able to easily replace this behavior. Unsure about shell.

Another potential issue is on multi-user systems. If both listen to acpi
events in this way there may be conflicts.

Alad

[1] https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
[2] https://wiki.archlinux.org/index.php/Acpid#Connect_to_acpid_socket
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20180118/71e6b94e/attachment-0001.asc>


More information about the aur-general mailing list