Grabs are now slice allocated structures that are handled by
whoever starts the grab. They contain a generic grab structure
with the interface and a backpointer to the MetaWaylandPointer.
The grab interface has been changed to pass full clutter events,
which allowed to remove the confusion between grab->focus and
pointer->focus. Invidual grabs are now required to keep their
focus, and choose whoever gets the events.
https://bugzilla.gnome.org/show_bug.cgi?id=707863
Once the sizing is properly wired up, we need to make sure that
the size at the initial map is correct, and not always 0, 0 because
the buffer is not yet converted into a CoglTexture by MetaShapedTexture,
otherwise we end up sending out configure events at 1 x 1.
To do so, we cache the surface type in the initial state until the
first commit.
https://bugzilla.gnome.org/show_bug.cgi?id=707401
To properly resize clients, we need to send them configure events
with the size we computed from the constraint system, and
then check if the new size they ask is compatible with
our expectation.
Note that this does not handle interactive resizing yet, it
merely makes the API calls work for wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=707401
Using the new Cogl API to actually modeset (because we can't
use the DRM API directly without controlling buffer swap), we
can finally have a KMS monitor backend, which means full display
configuration when running on bare metal.
https://bugzilla.gnome.org/show_bug.cgi?id=706308
The API was changed during the patch review.
(Yes, we were depending on API which was sitting in a patch not
yet reviewed... you know, vertical integration!)
https://bugzilla.gnome.org/show_bug.cgi?id=707929
Add MIN(...) with the interface version actually implemented
to all resource constructor, so that we never risk seeing requests
we don't implement (and consequently segfault)
https://bugzilla.gnome.org/show_bug.cgi?id=707851
Replace the deprecated APIs with the modern variants (which
also give us full control on the versioning).
Also, note that we only support version 2 of wl_seat. Version
3 is for multiple pointer/keyboards for a client, but
we don't implement that yet. If a client requests version 3
of wl_seat or make a version 3 request, it will get a protocol error.
https://bugzilla.gnome.org/show_bug.cgi?id=707851
We can't rely on clutter's xkb_state, because that's updated
when events are pulled from the kernel, not when we see them.
Instead, use the new clutter API to get the full modifier state
from the event (which, as a side effect, also works when clutter
is using the X11 backend for running nested).
https://bugzilla.gnome.org/show_bug.cgi?id=706963
Use the new Clutter hook to make sure the pointer never enters
the dead area caused by the different monitor sizes.
You don't realize how much X is doing for you until you lose it...
https://bugzilla.gnome.org/show_bug.cgi?id=706655
Add a new interface, gtk_shell, than can be used by gtk to
retrieve a surface extension called gtk_surface, which will be
used to communicate with mutter all the GTK extensions to EWMH
https://bugzilla.gnome.org/show_bug.cgi?id=707128
Add support for GTK application menus
To do so, we need to be able to set surface state before creating
the MetaWindow, so we introduce MetaWaylandSurfaceInitialState as
a staging area.
The gtk-shell-surface implementation would either write to the
initial state, or directly to the window.
At the same, implement set_title and set_class too, because it's
easy enough.
https://bugzilla.gnome.org/show_bug.cgi?id=707128
According to the wayland documentation, damage outside the
window size is ignored.
This happened with xwayland+wlshm (causing a GL error when calling
TexSubImage2D), probably due to not resizing the buffer
until we receive the corresponding X event.
Might also be an off-by-one in xwayland, as the window size did
not actually change.
Note: we might want to take the configure_notify path instead,
and keep the GL/clutter size consistent with wayland rather than
X, because in the end that's what matters for events and composition.
https://bugzilla.gnome.org/show_bug.cgi?id=706289
The protocol specification says that opaque / input regions should be
considered pending state and should only be actually swapped out when
the surface is committed, so it can be set atomically.
We had an assertion in meta_wayland_surface_free() that after
a repick() we would not choose the freed surface, but that didn't
consider surfaces destroyed while holding the implicit pointer
grab (ie, because the user clicked on the X button). In that case,
we need to bypass the grab infrastructure and explicitly unfocus
the dead surface.
https://bugzilla.gnome.org/show_bug.cgi?id=706982
After a MetaWaylandSurface is associated with a MetaWindow, it
should be freed only when the MetaWindow is unmanaged. For wayland
clients, the window is unmanaged when the resource is destroyed,
but for X11 clients we want to wait for the unmap event.
https://bugzilla.gnome.org/show_bug.cgi?id=705917
Calling XIGrabDevice has no effect under wayland, because the
xserver is getting events from us. Instead, we need to use our
own interfaces for grabs.
At the same time, we can simplify the public API, as plugins
should always listen for events using clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705917
We need to track the full xkb_state to have the necessary information
to send to the clients, otherwise they may get confused and lock
or invert the modifiers. In the evdev backend, we just retrieve the
same state object that clutter is using, while in the other backends
we fake the state using what clutter is providing (which is a subset
of what X11 provides, which would be necessary to have full state)
https://bugzilla.gnome.org/show_bug.cgi?id=705862
Now that we have a setuid launcher binary, we can make use of
using a private protocol through the socket we're passed at startup.
We also use the new hook in clutter-evdev to ask mutter-launch for
the FDs of the input devices we need, and we emulate the old X
DRM lock with a nested GMainContext without sources.
In the future, mutter-launch will be replaced with the new logind
API currently in development.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
Set the TTY mode appropriately at startup, and clean it up
when the compositor exits. Also, take control of VT switching,
including the calls to drmSetMaster and drmDropMaster as appropriate.
In the future, we the kernel implements the mute evdev ioctl,
we'll also make sure that input devices are appropriately released.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
Being a setuid binary, our LD_LIBRARY_PATH is cleared by glibc at
startup, but we need the spawned binary to see it, otherwise
jhbuild doesn't work, so hardcode it using the configured libdir.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
Remove the ability to launch as a different user, which we don't
need because we're spawned by gdm or by the user manually on the
command line.
At the same time, require an active local session, and remove
the ability to run from anywhere by being in the right user group
(which automatically gives you root-like privileges)
https://bugzilla.gnome.org/show_bug.cgi?id=705861
To run mutter as a display server, one needs to acquire and
release the DRM master, which is only possible for root, so
we take advantage of weston-launch, a small setuid helper binary
written for the weston project. We import our own slightly
modified copy of it, because weston-launch only launches weston,
for security reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
We need to track the full xkb_state to have the necessary information
to send to the clients, otherwise they may get confused and lock
or invert the modifiers. In the evdev backend, we just retrieve the
same state object that clutter is using, while in the other backends
we fake the state using what clutter is providing (which is a subset
of what X11 provides, which would be necessary to have full state)
https://bugzilla.gnome.org/show_bug.cgi?id=705862
