During xwayland initialization we run main loop and dispatch wayland
events, so that xwayland can initialize. If some client during this
phase connects and creates surface, mutter crashes because
it is not initialized yet. If we bind wayland socket after xwayland
is initialized and main loop is not running anymore, no client can
connect to mutter during initialization and that is what we want.
https://bugzilla.gnome.org/show_bug.cgi?id=751845
If the user Alt-Tabs out of the window, we will be left thinking
the Alt key is still pressed since we don't see a release for it.
Solve this and other related issues for the nested X11 compositor
by selecting for KeymapStateMask which causes a KeymapNotify event
to be sent after each FocusIn, and when we get these events, update
the internal XKB state and send any necessary modifiers events to
clients.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
The global wl_pointer_gestures object is now created, effectively
bridging pinch/swipe gestures with clients, so they're now
accessible to clients implementing the protocol.
MetaWaylandFrameCallback has been added a surface field, which is then
checked when destroying the surfaces. This prevents unintended callbacks
to run after a surface has been destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=745163
Add private functions for the test framework to use to find out the
wayland and x11 display names, so they can set up the environment for
children.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
The initialization sequence before was quite icky, initializing Clutter
in a few different places depending on what was going on.
Put that all back into main.c
I'm a bit tired of hearing about this when I launch mutter-wayland
nested. Ideally, this would be part of display server integration,
not GNOME integration, so we could simply not make the call when
nested, but oh well.
Previously, a sequence like this would crash a client:
=> surface.attach(buffer)
=> buffer.destroy()
The correct behavior is to wait until we release the buffer before
destroying it.
=> surface.attach(buffer)
=> surface.attach(buffer2)
<= buffer.release()
=> buffer.destroy()
The protocol upstream says that "the surface contents are undefined"
in a case like this. Personally, I think that this is broken behavior
and no client should ever do it, so I explicitly killed any client
that tried to do this.
But unfortunately, as we're all well aware, XWayland does this.
Rather than wait for XWayland to be fixed, let's just allow this.
Technically, since we always copy SHM buffers into GL textures, we
could release the buffer as soon as the Cogl texture is made.
Since we do this copy, the semantics we apply are that the texture is
"frozen" in time until another newer buffer is attached. For simple
clients that simply abort on exit and don't wait for the buffer event
anyhow, this has the added bonus that we'll get nice destroy animations.
In particular we need to know about all key events to keep the xkb
state reliable even if the event is then consumed by a global shortcut
or grab and never reaches any wayland client.
We also need to keep track of all pressed keys at all times so that we
can send an updated set or pressed keys to the focused client when a
grab ends.
https://bugzilla.gnome.org/show_bug.cgi?id=722847
