The 100%-cpu issue should be fixed upstream on master (and thus also in the -git package). I've mentioned this on the wiki:

https://wiki.archlinux.org/index.php/Power_management#xss-lock

I'll ask the author if he's still maintaining it. I might consider a fork otherwise.

On January 18, 2018 7:26:33 PM GMT+01:00, Pierre Neidhardt via aur-general aur-general@archlinux.org wrote:

The 100%-cpu issue should be fixed upstream on master (and thus also in the -git package). I've mentioned this on the wiki:

Why not simply backporting it via a patch file then?

Cheers, Levente

It's only 4 commits since 0.3.0, two of them being critical fixes. I could backport those two commits (just tried: no conflict); it feels needlessly pedantic however, compared to using "master" straight away.

I've contacted the developer, see if he replies within a few days. If not, I'll go ahead with the patches.

-- Pierre Neidhardt

Sodd's Second Law: Sooner or later, the worst possible set of circumstances is bound to occur.

On Thu, Jan 18, 2018 at 08:52:23PM +0100, Pierre Neidhardt wrote:

Alad Wenter via aur-general aur-general@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

On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:

This doesn't take care of locking on inactivity though, which is the other major feature of xss-lock.

Except, as noted, that "major feature" doesn't work at all...

Alad

On 01/18/2018 09:25 PM, Alad Wenter via aur-general wrote:

On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote: Except, as noted, that "major feature" doesn't work at all...

Doesn't it? It appeared to work when I tried it, and that was this morning...

Cheers, Bennett

On 01/18/2018 09:37 PM, Alad Wenter via aur-general wrote:

See the bug report I linked in the first reply.

https://bitbucket.org/raymonad/xss-lock/issues/17/does-not-report-activity-t...

Right, that is actually something else than what I did. I used `xset s` to trigger on inactivity, and xss-lock correctly locks the screen when that happens.

So it seems like it can still be used as a replacement for xautolock.

Cheers, Bennett

-------- Original Message -------- On January 19, 2018 11:52 AM, David Runge dave@sleepmap.de wrote:

Fwitw (and sorry for hijacking), I recently tried xprintidle (with a forked upstream, different from the one in the AUR) and it seems to work. This might still be used in a script to lock screens automatically under X, but it's clunky. I'd much prefer a more complete solution, as xautolock is aging (not so well) and at least in my case produces undesirable defuncts from time to time. xss-lock seemed too broken at that time, so I never used it. Are there any other alternatives not mentioned in the wiki?

I wrote xidle_dispatcher [0] myself, which I basically hook up to slock. Another tool I know of does basically the same thing, both being more or less what xssstate.c[1] does.

cheers! mar77i

[0] https://github.com/mar77i/xidle_dispatcher [1] https://git.suckless.org/xssstate/tree/xssstate.c

​ Sent with ProtonMail Secure Email.

Hi Pierre,

On 2018-01-23 10:14:12 (+0100), Pierre Neidhardt via aur-general wrote:

No answer from the dev so far, so I've packaged the latest commit as Eli suggested. Let me know if there is anything wrong.

nice to see this in [community]!

Could you also include a service file, that propagates the lock-sessions command, in the vein of what was suggested upstream [1]?

IMHO that would be very useful!

Best, David

[1] https://bitbucket.org/raymonad/xss-lock/issues/18/systemd-unit-for-locking-o...

On 2018-02-03 14:00:29 (+0100), Pierre Neidhardt wrote:

As far as I can tell, xss-lock is already run when I resume from a suspend.

Ah lol... I was under the impression, that xss-lock would need to be told to lock. It seems loginctl sends out the 'lock-sessions' after waking up from suspend by default.

I'm no systemd expert: what is the intent of the suggest systemd unit?

This would only ensure, that lock already happens right before suspend (in the case, someone wants that). This use-case gets around the problem of showing a small portion of what's going on in your DE/WM right after suspend and only then locking/blanking. IMHO locking before suspend is preferred, but that's probably a matter of taste.

Best, David

On 2018-02-03 14:41:33 (+0100), Pierre Neidhardt wrote:

You are probably right about that. I think however that this should be reported upstream to systemd rather than being part of the xss-lock package.

Hmm, I could find a (probably) related RFE [1].

[1] https://github.com/systemd/systemd/issues/6978