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 ;).
Before this commit, the background color (white by default) was visible for
about 100ms until the image was drawn. This flickering is now eliminated.
Also, we don’t need to handle Expose-events anymore, as X11 will use the
window’s background pixmap automatically.
As explained in Jamey’s post on the XCB mailing list, the event
loop can/should be written in a more simple way than it was before
in xcb-event. See:
<AANLkTinhIM320wUjSeHkBTVk4ysBuiSZkvfs8pMLVykO@mail.gmail.com>
or
http://lists.freedesktop.org/archives/xcb/2010-July/006292.html
When suspending your system to RAM, a race-condition can occur which
causes many enter keypresses to be sent. These effectively delay
your login by 3 seconds times 50 times (or so), so we just skip empty
passwords. If your password is empty, you don’t need to lock your
screen anyway.
Michael Stapelberg