Jasper St. Pierre authored Jan 22, 2016 and Rico Tzschichholz committed Jan 23, 2016

When cleaning up the logic in commit c408cf7a, I forgot to properly apply
de Morgan's laws to an inverse.

Reported by ricotz on IRC.

(cherry picked from commit 6fc51e37)

Update NEWS.

Colin Walters authored Sep 27, 2015 and Florian Müllner committed Oct 15, 2015

This tripped a new g-i warning; see
https://bugzilla.gnome.org/show_bug.cgi?id=752047

XInput2 uses the raw sequence number for XIEvent serials[0], which only
matches the serial number in XEvents up to 16 bits[1]. So in order to
be able to make reliable comparisons with serials from other events or
calls to XNextRequest(), always use the field from the original XEvent
rather than the XIEvent serial (at least until we can get libXi fixed).

This (partially) reverts commit 35dd1e64.

[0] http://cgit.freedesktop.org/xorg/lib/libXi/commit?id=5d43d4914dcabb6d
[1] http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/XlibInt.c#n265

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

Since commit 527c53a2, window->workspace is set to %NULL when
the window is sticky (see comment[0]), so don't try to save the
workspace index in that case.

[0] https://git.gnome.org/browse/mutter/tree/src/core/window.c#n4307

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

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

Still only compile-tested, but I was asked repeatedly to apply this
patch to 3-16, so let's try again ...

This reverts commit 55fd05ea.

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

Jasper St. Pierre authored Jun 24, 2015 and Florian Müllner committed Aug 01, 2015

For enter / leave events, which we use in the UI code, we need to make
sure that these coordinates are root-relative as well, otherwise the
cursor when entering frames might be incorrect.

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

Marek Chalupa authored Jul 03, 2015 and Michael Catanzaro committed Jul 15, 2015

We can get this operation in some cases, for example when
we're trying to resize window that cannot be resized.
This can occur with maximized windows that have a border
(without border we couldn't resize them by mouse in maximized state).
In this case we reached abort() beacuse we did not handle this op.

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

Peter Hutterer authored Jun 11, 2015 and Michael Catanzaro committed Jul 14, 2015

Before submitting a new scroll mode, click method or sendevents mode check if
the value is supported by the device. This avoids BadValue errors when setting
two-finger scrolling on single-finger touchpad devices since we can't easily
handle BadValue (see 9747277b)

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



Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Update NEWS.

A window may be hidden even if not minimized itself, for instance
when an ancestor is minimized. As meta_window_focus() will refuse
to actually focus the window in that case, don't pick it in the first
place.

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

Jasper St. Pierre authored Jun 23, 2015 and Florian Müllner committed Jun 26, 2015

When we're unredirected, we don't have a pixmap, and thus our allocation
becomes 0x0. So when events come in, they pass right through our actor,
going to the one underneath in the stack.

Fix this by having a fallback size on the shaped texture actor when
we're unredirected, causing it to always have a valid allocation.

This fixes clicking on stuff in sloppy / mouse mode focus.

Jasper St. Pierre authored Jun 23, 2015 and Florian Müllner committed Jun 26, 2015

In commit cc5def10, buttons were changed from GdkRectangles to
MetaButtonSpace units, but the corresponding memset hack was not.

This means that the clickable portion of the unshade rectangle
was always set to uninitalized memory. The effects of this were
random, but in cases where the moon is aligned just right, the
rectangle would graze over the borders, and so it would take priority
over other borders and show a pointer cursor instead of a resize
cursor.

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

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

window->is_alive isn't initialized explicitly so it defaults to FALSE
meaning that if the first ping fails we'd short circuit and not show
the delete dialog as we should.

We could initialize the variable to TRUE but in fact we don't even
need the variable at all since our dialog management is enough to
manage all the state we need, i.e. we're only interested in knowing
whether we're already displaying a delete dialog.

This does change our behavior here since previously we wouldn't
display the dialog again if the next ping failed after the dialog is
dismissed but this was arguably a bug too since in that case there
wouldn't be a way to kill the window after waiting for a while and the
window kept being unresponsive.

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

This makes gnome-settings-daemon turn on the backlight and
gnome-shell's screen shield animate.

Note that on X sessions, gnome-settings-daemon uses the same upower
property to force an innocuous key event into the X server so that the
idle time gets reset since Xorg doesn't do this itself on lid events.

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

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

Update NEWS.

Now that xf86-input-libinput exposes default values we can honor the
gsettings value.

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

We'll need to get the value of some properties. Fail if the number of
items returned is less than we expect and warn if it exceeds it so
that we can easily find out if items are added to a property later and
fix it.

The corresponding wl_notify field for destroy_data_device_icon()
is drag_grab->drag_icon_listener, otherwise we're fetching a pointer
that's slightly off where we want.

When running as an X11 compositor we do this for every event we see on
the X event stream. As a wayland compositor we don't go through that
code path but since we see all events we can easily do this on motion
events.

In fact, we don't even need this caching when we're a wayland
compositor since we can always find where the pointer is without a
round trip but we're sharing the current monitor logic with the X
path so let's keep it as is for now.

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

These events don't result from actual hardware events so we shouldn't
use them to reset idle time.

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

There is copy&pasted code in set_scroll_button, which is apparently
wrong, because it is trying to set scroll method instead of the scroll
button...

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

Update NEWS.

Carlos Garnacho authored Apr 15, 2015 and Rui Matos committed Apr 15, 2015

Since 8769b3d5, the checks performed on which update_* function was
called for each device got quite more lax, leading to failed asserts
on code that assumed the previous behavior.

Change update_[mouse|touchpad|trackball]_* to bail out early if the
device received has not the right type, and remove the asserts.

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

Update NEWS.

The scroll-wheel-emulation-button key is 'i' in the schema but it also
specifies a minimum range of 0 so using get_int() and casting is safe.

This makes the hotplug and coldplug paths the same so that we don't
miss out on any setting.

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