When no ignore_empty_password flag is specified, but Enter key is held
down for some time, i3lock enters a finite, but hours-long loop
verifying empty password. Don't do that, skip empty password
verification if nothing was pressed after last Enter keypress.
Again, making the software cat-proof.
When you start typing a password and then wander off, let's discard that
attempt after a few minutes of inactivity (and turn off the monitors if
dpms is on).
This is a real actual case of making the software cat-proof: when my cat
treads over the keyboard at night, I don't want the monitors to shine
for the rest of the night.
Also add flag for number of seconds to wait for it.
When user cancels the password or enters a wrong one, i3lock will wait
for some time before putting the monitors back to sleep. By default it's
30 seconds, but this flag allows to control that.
As described in ticket #1114, the screen may be left turned off on successful
authentication. This commit fixes this behaviour by turning the screen back on
after the authentication.
Fixes#1114
This is cleaner than commit a305e62 (running authentication in a
separate process) because we don’t lose the feature that X11 will buffer
KeyPresses for us while the process blocks on PAM. See
http://cr.i3wm.org/patch/305 for the amount of code (and new known bugs)
that would have to be introduced to make a305e62 work.
clear_input() calls start_clear_indicator_timeout() to clear the
indicator after 1 second. This had as a result the screen to be cleared
when the "verifying…" message was showed, so the "wrong!" message didn't
show up when the password was wrong.
First bad commit: a305e62
When having i3bar in “hide” mode, it could previously be brought up
while the authentication was running. This is not 100% fixed with this
change, but a lot better, as the normal “raise i3lock to the top”
behavior is not blocked now anymore.
fixes#895
When the XF86ScreenSaver key is used to put a laptop to sleep (or to
trigger the screensaver), the key may "bounce" on resume. This is
annoying as i3lock will try to validate several empty passwords and
wait several seconds before accepting a legit password.
Some users may want to validate an empty password: PAM may rely on
other sources to unlock the screen, like the presence of a token or
the proximity of some Bluetooth device. Hence, we don't forbid this
possibility and provide an command-line option for users not willing
to validate empty passwords.
Thanks to Ran Benita and Daniel Stone (the libxkbcommon authors) for
answering my questions and reviewing this code.
With this commit, input handling should be more correct with using less
code (in i3lock, that is).
With some layouts, this broke uppercase letters in your passwords.
I think that explicit shiftlock handling is unnecessary. X11 seems to do
it on its own. Here is what leads me to that conclusion:
$ setxkbmap de
$ xmodmap -e 'keycode 66 = Shift_Lock'
$ xev
Now enter a character, say "a", then press CapsLk (which is now
Shift_Lock), then press "a" again. The event state is 0x1, thereby
undistinguishable from normal shift.
See also:
http://article.gmane.org/gmane.linux.kernel/1268792
The C compiler will handle (void) as "no arguments" and () as "variadic
function" (equivalent to (...)) which might lead to subtle errors, such
as the one which was fixed with commit 0ea64ae4.
Daniel Otero