For compositors which support it (picom >v7.5, formerly known as compton), this
should result in the i3lock window no longer being composited, hence fixing
issue #204.
related to #204
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
Use the XComposite extension to get the composite overlay window,
instead of just using the normal root window. This ensures that
composited windows are covered.
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.
We need to ensure that the window handle is valid, i. e. the window is
actually created and accessible, before returning.
This is necessary because we immediately fork after returning, and the
child process opens its own X11 connection and expects the window handle
to be valid.
Fixes#46
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
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).
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
Michael Stapelberg