[PATCH 0/3] XWayland: Support focus key array correctly

[Daniel Stone]

Hi,
This one has a pretty long and tortured history, beginning with:
https://bugzilla.gnome.org/show_bug.cgi?id=727178

and culminating in:
http://lists.freedesktop.org/archives/wayland-devel/2014-November/018268.html

and the related thread.

The tl;dr for those of you not wishing to read an 80-page thread, is that
we correctly send wl_keyboard::enter events (Wayland's equivalent of
FocusIn + KeymapNotify) to clients with the full list of depressed keys
when we give them the keyboard focus.

Unfortunately, XWayland quite naïvely just posts them through as full
key presses, meaning that if you have Super+S as a screenshot binding,
the compositor will return the focus with S held down, XWayland will
send a KeyPress for S, and you'll then get a stray letter in your
terminal, or whatever.

There's no good support in the server for handling keys still down on
enter, and it's not really a wonder why. In xkbcommon, we separated
the state machinery out from key presses somewhat, so it's pretty
trivial. But with in-server XKB, we don't really have a choice but
to run the full XKB machinery.

This patch series attempts to tame the damage somewhat by adding a new
ET_KeyFocusIn internal event, which is plumbed from KeymapNotify in
QueueKeyboardEvents & co. This does everything but send KeyPress events
to clients, and also suppresses some of the stronger XKB actions, e.g.
if you have Ctrl+Alt+Backspace down as you _enter_, you won't then
immediately terminate your server.

XWayland is then trivially modified to send the keys through this on
focus, instead of sending KeyPresses. Xephyr could definitely benefit
from the same, but that is not a job for 10:35pm on a Friday night.

Ultimately, it would be nice to have a similar mechanism to xkbcommon
where we can inherit the resultant state (i.e. 'this set of modifiers
is currently down') from the parent server, and not have to run the
XKB state machinery at all, but I couldn't easily see how to make
that work in the face of things like modifierKeyCount.

This should be safe enough to apply to a stable series as well; it does,
strictly speaking, add an internal event type, but it is to the end of
the list, and I can't see it changing any other ABI. The only
case would be if external modules blithely sent KeymapNotify to servers
which were unaware, but, eh. (Maybe a minor input ABI bump?)

The XKB behaviour definitely isn't perfect, but it's also objectively
an improvement over previous, so.

Cheers,
Daniel