| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
This reverts commit a305e622a6cad3f9ba267d6810fee54b7c7c86c3.
In the next commit, the same functionality will be achieved in a cleaner
way.
|
|
This reverts commit 33d953fbdf4f8630e919643974f32ce6793c7c2b,
in preparation for reverting commit a305e62
|
|
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
|
|
This should make the numpad work correctly.
|
|
|
|
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.
|
|
|
|
|
|
This has been broken by commit 661344.
|
|
|
|
|
|
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
|
|
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
|
|
|
|
This keysym is generated on convertible tablets by pressing a hardware
lock/unlock button.
|
|
|
|
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).
|
|
The previous code didn’t cause any issues since both types (currently!)
have the same size.
|
|
|
|
|
|
On ARM, casting -1 to char turns it into something else. Fixes
argument parsing on ARM. Thanks Chipaca for reporting.
|
|
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.
|
|
(Thanks xn)
Fixes: #712
|
|
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.
|
|
If the specified file does not exist or is invalid, previously, the unlock
indicator wouldn’t show up at all, because the invalid surface was still used.
With this commit, i3lock will react like if you didn’t specify an image at all.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ISO_Level3_Shift thing
|
|
I tested this with the following experiment:
$ setxkbmap 'us(intl)'
$ xmodmap ~/configfiles/midna/Xmodmap
$ xmodmap -e 'keycode 38 = a A adiaeresis Adiaeresis o O'
$ xmodmap -e 'keycode 49 = ISO_Level3_Shift ISO_Level3_Shift ISO_Level3_Shift ISO_Level3_Shift'
Then, Mode_switch + a yields ä, but ` + a yields o.
In i3lock, these were swapped (Mode_switch + a yielded o, while ä was not
reachable at all). The comment in the code explains it
(See http://code.stapelberg.de/git/configfiles for the Xmodmap)
|
|
This fixes bug http://bugs.i3wm.org/545, where characters (of your password)
would rarely slip through when entering your password (especially) after
resuming your notebook from suspend to RAM.
The reason is that when resuming, X triggers one or more MappingNotify events.
At the same time, CPU load is high. This leads to a race-condition between the
ungrab and re-grab in which i3lock temporarily does not grab the keyboard.
One way to fix this is using xcb_grab_server() before and xcb_ungrab_server()
after the ungrab/re-grab. However, I think we actually don’t need to
ungrab/re-grab at all. I seem to have put that code in here by mistake – in i3,
we re-grab after MappingNotify, but there we only grab specific keys. In
i3lock, we grab the whole pointer/keyboard, so there should be no need.
If I’m incorrect and this breaks some subtle use-cases for people with strange
layout setup, at least we can properly document on why we need it, after we put
it back in ;).
|
|
TrickSTer)
|
