FR: Emit a lock event on lock

[kiprasmel]

I'm submitting a…

[ ] Bug
[x] Feature Request
[ ] Other (Please describe in detail)

Current Behavior

It seems like neither i3 nor i3lock emit a lock event.

Expected Behavior

It would be great if i3lock / i3 could emit a lock event on screen lock that would allow other applications to capture and act upon it.

Environment

Output of i3lock --version:

i3lock: version 2.11.1 © 2010 Michael Stapelberg

$ uname -a
Linux arch-usb 5.2.0-arch2-1-ARCH #1 SMP PREEMPT Mon Jul 8 18:18:54 UTC 2019 x86_64 GNU/Linux

Related

This originally came from keepassxreboot/keepassxc#3339 - a password manager could lock it's database on screenlock, but that currently doesn't seem possible with i3 / i3lock, since there's no lock event (correct me if I'm wrong).

I'm sure there'd be more use cases:)

[Airblader]

What kind of event are you referring to, specifically? Is there some standardized protocol to implement against? How do other locking tools do it?

[orestisfl]

keepassxc (keepassxreboot/keepassxc#545) uses the dbus notification to lock the database. IIUC, using loginctl lock-session according to https://wiki.archlinux.org/index.php/Session_lock#DBUS_Notification should emit the correct notification.

I wasn't able to make this work on my system but if you figure it out, you can easily replace whatever way you use to lock your system with loginctl lock-session.

[kiprasmel]

@orestisfl Thanks for the info. I've tried out loginctl lock-session[s], but it doesn't seem to do anything on my arch linux i3 setup.

@Airblader I'm not as advanced here, I think that @droidmonkey could help answering these questions:)

[Holzhaus]

IMHO i3lock should set the LockedHint property. It was implemented in systemd in this PR: systemd/systemd#3238
Support was added to ConsoleKit in this commit: ConsoleKit2/ConsoleKit2@d28abf1

[droidmonkey]

That seems like a good approach

[Airblader]

I agree, following this would be good because it's a centralized effort. I'm not sure about adding dbus to i3lock for it, though. @stapelberg what are your thoughts?

[stapelberg]

I agree that the goal of having loginctl know the session is locked is a good goal, and I have wanted this feature in the past myself :)

That said, I do wonder if xss-lock should be the place where that signal gets sent, because that’s what we currently rely on for integrating with logind. Could it be done there? That approach has the nice side-effect that other niche screen lockers used via xss-lock would also benefit.

[liskin]

@stapelberg Indeed it can be done in xss-lock, there are patches for it: https://github.com/xdbob/xss-lock/compare/locked_hint
Unfortunately xss-lock upstream seems to be dead (there's been a request for LockedHint since 2017) so there are several forks and distributions carry various patches as well. :-(

[stapelberg]

That’s a shame. Let’s hope xss-lock finds someone who’s interested in maintaining it.

[christianparpart]

I am interested in this, too. Because tools, such as screenkey could make use of such a DBus event, too. Is there any update on this?

[bitshiftnetau]

Does i3 currently have an unlock event? I keep losing my Pulseaudio config on lock and need to restart it every time.

[Airblader]

It does not, but your issue sounds very much unrelated to screen locking and should probably be addressed differently anyway.

[stapelberg]

If you want to run commands when i3lock exits, just wrap i3lock -n in a shell script. See the example in https://manpages.debian.org/testing/i3lock/i3lock.1.en.html#DPMS

[a-pav]

If you want to run commands when i3lock exits, just wrap i3lock -n in a shell script. See the example in https://manpages.debian.org/testing/i3lock/i3lock.1.en.html#DPMS

What's the purpose of the trap line? Apparently using -n pauses the script from continuing until the correct password is entered, so, it seems, a revert after i3lock -n should be enough.

[stapelberg]

The trap line ensures the cleanup happens regardless of how the script terminates (interrupted with a signal, for example).

It might not be strictly necessary in this particular form of the shell script, but I consider it good practice (see “defensive programming”), in particular for scripts that people might reasonably modify to become more complex.