search

i3 / i3lock

improved screen locker
https://i3wm.org/i3lock
BSD 3-Clause "New" or "Revised" License
920 stars 404 forks source link

refresh image upon receiving USR1 #299

Closed mfontani closed 3 years ago

mfontani commented 3 years ago

Hi,

I've been using these proposed two patches on top of i3lock for quite some time now, and I'm testing the waters about whether they could be merged upstream instead of sitting in a branch, with no other user than myself.

The point of those patches is to allow refreshing the image used for locking the screen upon receiving a signal (i.e. USR1).

As to the use-case...

When one wants to use an amended screenshot of the current screen to lock their screen, they usually proceed as follows:

  1. take screenshot
  2. manipulate screenshot image
  3. call i3lock with the manipulated image

The step at "2." may take quite a bit of time, and while "2." performs its tasks the screen isn't yet locked. If "2." moreover fails, it's possible the screen is never effectively locked.

With these patches, my process is now:

  1. take screenshot
  2. call i3lock with the just-screenshotted image (quick, and the screen is now locked)
  3. manipulate screenshot image (may take however long, screen is still locked)
  4. pkill -USR1 i3lock, which refreshes the image (screen is still locked, but now displays the new image)

In case the "3." step above takes an inordinate amount of time or fails, the screen is locked.

stapelberg commented 3 years ago

Thanks for your PR.

Given that i3lock is a security-sensitive program, I would rather not have it reload anything in lock state. Even small mistakes, like a 1-byte memory leak, can manifest themselves as a lock screen circumvention bug.

xPMo commented 3 years ago

More features are often accepted in i3lock-color.