Instead of returning a value based on whether or not we handled it, we
have this logic: either we have taken a grab on the window, in which
case we have a grab op and have handled it ourselves, or we did not take
a grab and *need* to replay the event to the window.
Handle this in events.c by checking the grab operation in the same way
that we check the other grab ops.
This is an accidental regression from 7a109a1. If we mark the event as
handled, then we *need* to set grab_op, or do some other sort of
behavior, since we have a grab.
meta_backend_get_keymap is supposed to return a static keymap, not a new
one every time. Cache it internally. We don't update it when the keymap
changes on the server, but we'll do this soon.
Now that we always use XKB, it's very unlikely that we'll get a
MappingNotifier without a subsequence XkbKeymapNotify event. Just
do all the work always.
This will also help us considerably for the future when we'll be
putting the keymap event in the backend.
This allows creating the stage much earlier than it otherwise would have
been. Our initialization sequence has always been a bit haphazard, with
first the MetaBackend created, then the MetaDisplay, and inside of that,
the MetaScreen and MetaCompositor.
Refactor this out so that the MetaBackend creates the Clutter
stage. Besides the clarity of early initialization, we now have much
easier access to the stage, allowing us to use it for things such as
key focus and beyond.
Mutter depends on the X11 windowing backend of Clutter, unless it's used
as a Wayland display server.
This allows Mutter to run without breaking in case Clutter changes the
order with which windowing backends are selected, like it was the case
for bug https://bugzilla.gnome.org/show_bug.cgi?id=734587
The order of selection of the Clutter backends has not been made public,
so it cannot be relied upon since the introduction of the multiple
backends support; since Mutter requires the X11 backend functionality,
it should select the X11 windowing system, in the same way it selects
the EGL backend when compiled and run as a Wayland display server.
If we for some reason have an error trying to allocate the framebuffer,
we'll still mark the tower as revalidated. Move the validation to the
end of the actual revalidation code to solve this.
It's a deprecated API that can surprise us. Namely, when the internal
format passed is COGL_PIXEL_FORMAT_ANY, it will *always* allocate an
RGBA8888 pixel format texture, even if we only passed it a RGB format
or even an A8 format.
cogl_texture_2d_new_with_data is the newer, better API and doesn't have
these warts.
These methods allow us to set and get xkbcommon keymaps as well as
locking a specific layout in a layout group.
With this, we introduce dependencies on xkeyboard-config, xkbfile,
xkbcommon-x11 and a libX11 new enough to have xcb support.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
At this point there shouldn't be any system capable of running mutter
that doesn't have it and we're introducing functionality like setting
the keymap that has an hard requirement on it.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
