Since mutter has two X connections and does damage handling on the
frontend while fence triggering is done on the backend, we have a race
between XDamageSubtract() and XSyncFenceTrigger() causing missed
redraws in the GL_EXT_X11_sync_object path.

If the fence trigger gets processed first by the server, any client
drawing that happens between that and the damage subtract being
processed and is completely contained in the last damage event box
that mutter got, won't be included in the current frame nor will it
cause a new damage event.

A simple fix for this would be XSync()ing on the frontend connection
after doing all the damage subtracts but that would add a round trip
on every frame again which defeats the asynchronous design of X
fences.

Instead, if we move fence handling to the frontend we automatically
get the right ordering between damage subtracts and fence triggers.

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

Ting-Wei Lan authored Aug 08, 2015 and Rui Matos committed Aug 13, 2015

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

Aaron Plattner authored Aug 03, 2015 and Rui Matos committed Aug 13, 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

Mutter uses a function from libXrender (XRenderFindStandardFormat in
src/x11/iconcache.c), but doesn't link to libXrender. This causes
link issues on systems using the gold linker, particularly with
-Wl,--as-needed.

Since mutter is using a function from libXrender, adding 'xrender'
as a dependency seems appropriate, and fixes the issue.

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

Update NEWS.

Since commit 6e06648f, we start out with the invisible frame parts
only, and then add the unconstrained rect's height (which consists of
the visible parts of both frame and client window) *unless* the window
is shaded. While we indeed don't want to add the client height in that
case, we need to explicitly include the visible frame parts now.

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

We need to reload the FBOs under some circumstances, this adds a way
to easily do so.

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

Implicit conversion from int to float is not supported by
GLSL ES.

Fixes:
(gnome-shell:8954): Cogl-WARNING **: Shader compilation failed:
1:2: P0004: High precision not supported, instead compiling high precision as medium precision
4:17: S0001: Type mismatch in arithmetic operation between 'int' and 'float'
when one trigger the overview mode on Mali 400 r1p1 GPU.

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

The current ordering updates the clip shape of the composite overlay
window after unredirecting the target window. This has the effect of
forcing X to clear the target window and sending an expose to the
application to repaint - causing an unsightly flash. If we update the
shape first, then unredirect, X restores the background of the root
window (sending no expose events as no one is interested) and the
background is typically NONE for the root window. Then the unredirect
paints the contents of the composite backing pixmap over top without
requiring a round trip and waiting for the client to repaint - thus no
flashing.

Fixes regression from

commit d6282716


Author: Jasper St. Pierre <jstpierre@mecheye.net>
Date:   Fri Dec 6 17:10:44 2013 -0500

    compositor: Simplify the unredirected window management code

Cc: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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

We were regarding META_GRAB_OP_KEYBOARD_RESIZING_UNKNOWN as a move.

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

When looking for space to place a new window, other non-minimized
windows on the same workspace should be taken into account. However
the current check does not work correctly when the placed window is
located on all workspaces, so handle that case explicitly.

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

We have depended on GTask for a while now, bump the GLib requirement
to a new enough version to include that.

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

Update NEWS.

This optimization breaks our use of XRRScreenResources' timestamps to
detect hotplugs in case one of the outputs is disconnected and the
remaining ones don't need any mode, position or transform adjustments.

In that scenario, when applying the new configuration, we resize the X
screen but never call XRRSetCrtcConfig() and since XRRSetScreenSize()
doesn't take a timestamp and the X server doesn't update its last set
timestamp, when we next get a RRScreenChangeNotify and update
ourselves, XRRScreenResources.timestamp will still be smaller than
XRRScreenResources.configTimestamp which makes us think we're seeing a
new hotplug. We just don't enter an endless loop because the screen
size that we keep applying is always the same and the X server
short-circuits and stops sending us RRScreenChangeNotifys.

Always calling XRRSetCrtcConfig() ensures that the last set timestamp
will be bigger than configTimestamp in the next event and thus making
us trigger the monitors-changed signal properly.

Note that the X server already does basically the same checks that
we're removing here, so doing this shouldn't be a significant
efficiency loss. See

http://cgit.freedesktop.org/xorg/xserver/tree/randr/rrcrtc.c?h=server-1.16-branch#n539

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

If the app finished multiple frames before we sent _NET_WM_FRAME_DRAWN,
we could add the send_frame_messages_timer multiple times. In the rare
case that the app immediately closed the window, the older timeout
could potentially then run on the freed actor.

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

* Use -1 rather than 0 as a flag for pending queue entries; 0 is
  a valid frame_counter value from Cogl.
* Consistently handle the fact we can have more than one pending
  entry. It's app misbehavior to submit a new frame before
  _NET_WM_FRAME_DRAWN is received; but we accept such frame messages,
  so we can't just leak them.
* If we remove send_frame_message_timer, assign the current frame counter
  to pending entries.
* To try to avoid regressing on this, when sending _NET_WM_FRAME_TIMINGS
  messages, if we have stale messages, or messages with no frame drawn
  time, warn and remove them from the queue rather than just accumulating.
* Improve commenting.

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

Windows that set empty input shapes get n_rects of 0 when querying them
later, which makes sense, but the code that interpreted the result
translated it into a NULL input shape, which meant it was the same as
the bounding region. As such, an empty input shape would actually get
interpreted as a full input shape!

We, ourselves, set an empty input shape on tray icon windows in
gnome-shell since we would handle the picking ourselves. This meant that
we'd actually get the MetaSurfaceActorX11 when hovering over the tray
icon, instead of the ShellGTKEmbed that we capture events on and react
to.

This fixes weird tray icon behavior in gnome-shell.

This reverts commit ec8ed1db.

1) It turns out to add a momentary flicker from the transition
between the login screen and user session
2) It actually isn't needed anymore since bug 733026

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

WindowActors can outlive their corresponding window to animate unmap.
Unredirecting the actor does not make sense in that case, so make
sure to not request it.

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

Update NEWS.

Jasper St. Pierre authored Oct 15, 2014 and Rui Matos committed Nov 10, 2014

Whoops, I made the code work without it, but forgot to strip it from the
actual list of requires packages.

Spotted-by: Rico Tzschichholz <ricotz@ubuntu.com>

Jasper St. Pierre authored Oct 15, 2014 and Rui Matos committed Nov 10, 2014

Now it's only required by the native backend. The cursor code is getting
quite messy, but it was already considerable messy to start with.

Jasper St. Pierre authored Oct 15, 2014 and Rui Matos committed Nov 10, 2014

Reverse the set of expressions so testing for gbm is at the top.

The important thing is whether this property exists or not, but the value
doesn't matter.

meta_monitor_config_match_current() only matches the number of outputs
and if the output connector, vendor, product and serial match.

This means that we can't use it to bypass doing any
work because it won't detect cases where we actually want to update
ourselves like e.g. an output being turned off either by us or by
another X client (e.g. xrandr).

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

When a laptop's lid is closed we try to build and apply a temporary
configuration that disables the laptop's display if we have other
outputs.

This isn't enough though, we must also check if at least one of these
other outputs is enabled otherwise we'll try to resize the screen to
0x0 which (rightfully) hits an assertion.

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

Update NEWS.

The input region currently only gets scaled by the surface
scale while ignoring the output scale, which causes input events to not get
delivered correctly for clients on hidpi screens. So take the output scale
into account when doing so.

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

This commit is wrong, it assumes that the scale only applies to the one
set by the client but its not. meta_surface_actor_wayland_scale_texture
also handles the output scale. Revert the commit to fix hidpi for wayland
clients like weston-terminal.

This reverts commit 0364ea91.

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

Jasper St. Pierre authored Oct 14, 2014 and Kalev Lember committed Oct 15, 2014

Commit 2f9c601a

 accidentally changed the logic here, changing the grab
behavior when not using raise-on-click. Fix this.

Spotted-by: Adam Goode <adam@spicenitz.org>

Update NEWS.