The code now tries the following options, in order:
• obtain monitors via RandR 1.5
• obtain outputs via RandR ≤ 1.4
• obtain screens via Xinerama
fixes#159
related to #101
related to #148
related to #149
When grabbing the pointer/keyboard fails, a new code path is activated, which:
1. Uses the standards-compliant _NET_ACTIVE_WINDOW root window property to
determine the window to restore focus to.
2. Sets the input focus to the i3lock window, thereby possibly force-closing
open context menus (works with e.g. Google Chrome, does not work with
e.g. thunar, gedit).
3. Upon exiting, restores focus to the window from step ① by sending a
_NET_ACTIVE_WINDOW ClientMessage to the root window. Note that this step
requires https://github.com/i3/i3/pull/3027 in i3 to not mess up focus.
fixes https://github.com/i3/i3lock/issues/35
Display "locking…" message when grabbing the pointer/keyboard,
after at least 250 ms of unfruitful attempts. If grabbing
eventually fails, application will not fork and return 1.
This will make i3 unlock automatically after authentication failure and
correct input without pressing <Enter> again after the "wrong"-indicator
is gone.
When the unlock indicator warns the user that a password was typed
wrong, it now also reports the state of the capslock and numlock
modifiers.
Signed-off-by: Alexandre Boeglin <alex@boeglin.org>
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.
Michael Stapelberg