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.

The pinch gesture resources are part of the MetaWaylandPointerClient, which
will be used during the propagation of CLUTTER_TOUCHPAD_PINCH events.

The swipe gesture resources are part of the MetaWaylandPointerClient, which
will be used during the emission of CLUTTER_TOUCHPAD_SWIPE events.

Jonas Ådahl authored Aug 09, 2015 and Carlos Garnacho committed Aug 10, 2015

Instead of moving around all the bound pointer resources for a client
when changing focus, keep all the resources bound by a client in a per
client struct, and track the focus by having a pointer to the current
active pointer client struct instance.

This will simplify having wl_pointer extensinos sharing the pointer
focus of the wl_pointer by only having to add them to the pointer
client.

https://bugzilla.gnome.org/show_bug.cgi?id=744104

https://bugzilla.gnome.org/show_bug.cgi?id=753380

The spec says:
"A server should avoid signalling the frame callbacks if the surface is not
visible in any way, e.g. the surface is off-screen, or completely obscured
by other opaque surfaces."

We actually do have the information to do that but we are always calling
the frame callbacks in after_stage_paint. So fix that to only call when
when the surface gets drawn on screen.

https://bugzilla.gnome.org/show_bug.cgi?id=739163

Aaron Plattner authored Aug 03, 2015 and Rui Matos committed Aug 07, 2015

The compositor maintains a ring of shared fences with the X server in order to
properly synchronize rendering between the X server and the compositor's GPU
channel.  When all of the fences have been used, the compositor needs to reset
one so that it can be reused.  It does this by first waiting on the CPU for the
fence to become triggered, and then sending a request to the X server to reset
the fence.

If the compositor's GPU channel is busy processing other work (e.g. the desktop
switcher animation), then the X server may process the reset request before the
GPU has consumed the fence.  This causes the GPU channel to hang.

Fix the problem by having the compositor's GPU channel trigger its own fence
after waiting for the X server's fence.  Wait for that fence on the CPU before
sending the reset request to the X server.  This ensures that the GPU has
consumed the X11 fence before the server resets it.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

https://bugzilla.gnome.org/show_bug.cgi?id=728464

If GL advertises this extension we'll use it to synchronize X with GL
rendering instead of relying on the XSync() behavior with open source
drivers.

Some driver bugs were uncovered while working on this so if we have
had to reboot the ring a few times, something is probably wrong and
we're likely to just make things worse by continuing to try.  Let's
err on the side of caution, disable ourselves and fallback to the
XSync() path in the compositor.

https://bugzilla.gnome.org/show_bug.cgi?id=728464

Windows can disappear at any time because X11 is really cool and good,
so just use XCB so we won't crash if the window disappears.

Instead of silently failing without the client noticing.

https://bugzilla.gnome.org/show_bug.cgi?id=753237

If we can't put up a popup because grabbing the pointer fails we
immediately dismiss the popup but the client might have made requests
already, in particular it might have commited the surface and in that
case we should ignore it.

https://bugzilla.gnome.org/show_bug.cgi?id=753237

Don't only release it, also close the fd so that we don't leak it.

https://bugzilla.gnome.org/show_bug.cgi?id=752753

When a client sets an input region or a opaque region to NULL, it
should still be considered a change to the corresponding region on the
actor. This patch makes sure this state is properly forwarded.

https://bugzilla.gnome.org/show_bug.cgi?id=753222

This was introduced in commit c6793d47
to prevent window self-maximisation. It turns out that that bug seems
to have been fixed meanwhile in a different way since the reproducer
in https://bugzilla.gnome.org/show_bug.cgi?id=461927#c37 now works
fine with this special handling removed.

In fact, failing to set window->fullscreen immediately when loading
the initial set of X properties causes us to create a UI frame for a
window that sets _NET_WM_STATE_FULLSCREEN.

This, in turn, might cause the fullscreen constrain code to fail if
the window also sets min_width/min_height size hints to be the monitor
size since the UI frame size added to those makes the rectangle too
big to fit the monitor. If the window doesn't set these hints, we
fullscreen it but the window will get sized such that the UI frame is
taken into account while it really shouldn't (see the reproducer
above).

https://bugzilla.gnome.org/show_bug.cgi?id=753020

Update NEWS.

meta_window_change_workspace_without_transients() already does
exactly that.

meta_window_change_workspace_without_transients() already does
exactly that.

The definition was removed long ago in commit ff33209e ...

Unused since commit bf64e719 (2001!) ...

Since commit 14b0a83f we store the
main window monitor instead of computing it every time. This means
that we must now ensure that it's updated before trying to use it
which we do from meta_screen_resize_func() or else we'll crash on an
assertion later on when removing a monitor:

assertion failed: (which_monitor < workspace->screen->n_monitor_infos)

https://bugzilla.gnome.org/show_bug.cgi?id=752674

Some monitors return a bunch of bytes on their display descriptor
which aren't valid utf8 and thus we fail to serialize them later on
for the DisplayConfig DBus API.

Let's fall back to the stringified product code and serial number in
that case.

https://bugzilla.gnome.org/show_bug.cgi?id=752673

The code for setting an anchor was comparing apples and oranges.
This was pointed out by coverity.

https://bugzilla.gnome.org/show_bug.cgi?id=752552

The code was checking width twice, instead of width and height,
as was clearly the intention. Coverity pointed this out.

https://bugzilla.gnome.org/show_bug.cgi?id=752551

We will need to update the timeout on either cursor changes, or
right when ticking to the next cursor frame.

https://bugzilla.gnome.org/show_bug.cgi?id=752342

There will be times where additional updates will be needed, such
as animated cursors. We should update the texture and redraw in
that case.

https://bugzilla.gnome.org/show_bug.cgi?id=752342

There's a chance the icon will be animated, so store the XcursorImages
instead of the individual XcursorImage, and handle that as a nimages=1
special case.

API to "tick" a cursor animation, and retrieve current frame timing
information has been added.

https://bugzilla.gnome.org/show_bug.cgi?id=752342

They otherwise fall through paths that enable bypass_clutter, this
is necessary so they can be picked by captured-event handlers
along the actor hierarchy.

https://bugzilla.gnome.org/show_bug.cgi?id=752248

Take the surface actor scale into account when calculating the window
geometry.

https://bugzilla.gnome.org/show_bug.cgi?id=744934

When placing a popup and the legacy transient wl_shell_surface surfaces,
take the current scale of the window into account. This commit doesn't
fix relative positioning in case a window scale would change, but since
the use case for relative positioning is mostly popups, which would be
dismissed before the parent window would be moved, it should not be that
much of a problem.

https://bugzilla.gnome.org/show_bug.cgi?id=744934

Make meta_wayland_surface_get_toplevel_window return the top most window
in case its a chain of popups. This is to make all popups in a chain
including the top most surface have the same scale.

The reason for this is that popups are mostly integrated part of the
user interface of its parent (such as menus). Having them in a different
scale would look awkward.

Note that this doesn't affect non-popup windows with parent-child
relationship, because such windows are typically not an integral part of
the user interface (settings window, dialogs, ..) and can typically be
moved independently. It would probably make sense to make attached modal
dialogs have the same scale as their parent windows, but modal dialogs
are currently not supported for Wayland clients.

https://bugzilla.gnome.org/show_bug.cgi?id=744934

Since we scale surface actors given what main output their toplevel
window is on, also scale the window geometry coordinates and sizes
(window->rect size and window->custom_frame_extents.top/left) in order
to make the window geometry represent what is being rendered on the
stage.

https://bugzilla.gnome.org/show_bug.cgi?id=744934

The main monitor of a window is maintained as 'window->monitor' and is
updated when the window is resized or moved. Lets avoid calculating it
every time it`s needed.

https://bugzilla.gnome.org/show_bug.cgi?id=744934

Tracking back from the monitor to the output every time we need to
figure out the scale of a window on a monitor is inconvenient, so
propagate the scale from the output to the monitor it is associated
with.

https://bugzilla.gnome.org/show_bug.cgi?id=744934

A MetaWaylandSurface was casted into a ClutterActor, but it should have
been the MetaSurfaceActor.

Move out parent_actor and surface_actor out of the loop while at it
since they won't change when iterating.

https://bugzilla.gnome.org/show_bug.cgi?id=745655

Keep the active position state in its original coordinate space, and
synchronize the surface actor with it when it changes and when
synchronizing the rest of the surface state, in case the surface scale
had changed.

https://bugzilla.gnome.org/show_bug.cgi?id=745655

Put a toplevel window getter in meta-wayland-surface.h and a main
monitor scale getter in window-wayland.h.

https://bugzilla.gnome.org/show_bug.cgi?id=745655