We must send frame_drawn and frame_timing messages to even when
we don't actually queue a redraw on screen to comply with the
WM sync spec.
So throttle such apps to down to a ~100ms interval.
https://bugzilla.gnome.org/show_bug.cgi?id=703332
When we get a damage event we update the window by calling
meta_shaped_texture_update_area which queues a redraw on the actor.
We can avoid that for obscured regions by comparing the damage area to
our visible area.
This patch causes _NET_WM_FRAME_DRAWN messages to be not sent in some cases
where they should be sent; they will be added back in a later commit.
https://bugzilla.gnome.org/show_bug.cgi?id=703332
When drawing entirely opaque regions, we traditionally kept blending on
simply because it made the code more convenient and obvious to handle.
However, this can cause lots of performance issues on GPUs that aren't
too powerful, as they have to readback the buffer underneath.
Keep track of the opaque region set by windows (through _NET_WM_OPAQUE_REGION,
Wayland opaque_region hints, standard RGB32 frame masks or similar), and draw
those rectangles separately through a different path with blending turned off.
https://bugzilla.gnome.org/show_bug.cgi?id=707019
Split out pipeline creation to a separate function so that we don't
have so much dense code in the paint function itself, and remove some
indentation levels.
Also, don't use our own template for the unmasked pipeline, since it
has nothing different from the default pipeline template.
We also don't store the pipelines anymore since their creation isn't
really helping us; we set the mask texture and paint texture on every
paint anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=707019
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
The user active watch is a one-fire watch, but it is valid in the API
for the callback to explicitly remove the watch itself. In that case,
the watch will be invalid after the user removes it, and the memory
potentially freed. So make sure to not dereference the watch after
the callback is called.
https://bugzilla.gnome.org/show_bug.cgi?id=706825
Dialogs that don't have a parent should not be skip-taskbar,
otherwise they get lost and there is no way to recover them
(because they're not autoraised when activating the parent),
but toolkits and applications set the hint anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=673399
Modify all visible instances of mutter with mutter-wayland
(libraries, folders, pkgconfig, etc.), so that the wayland
branch can be installed alongside the usual X11 mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705497
In the wayland branch of mutter, we want to build a wayland version
of the mutter libraries, and that's much easier if we just build
wayland support unconditionally.
The define is kept to avoid a huge diff, but should be removed
in a later patch.
Also, wayland support can still be disable at runtime, by
launching mutter without the --nested switch.
https://bugzilla.gnome.org/show_bug.cgi?id=705497
If we're attempting to reconfigure the CRTCs to the same parameter,
skip the X call, as in some drivers a modeset can take time and
cause flicker.
https://bugzilla.gnome.org/show_bug.cgi?id=706672
To allow other clients (gnome-session, gnome-settings-daemon)
to monitor user activity, introduce a DBus interface for the
idle monitor inside mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=706005
When running as a wayland compositor, we can't use the xserver's
IDLETIME, because that's updated only in response to X events.
But we have all the events ourselves, so we can just run the timer
in process.
https://bugzilla.gnome.org/show_bug.cgi?id=706005
We can't use the X11 stage window, if clutter is not using the X11
backend (and even if it was, it would be bogus when the xwayland
server is not the one clutter is talking to). Instead, we introduce
the concept of "focus type", which we use to differentiate the
various meanings of None in the focus_xwindow field.
https://bugzilla.gnome.org/show_bug.cgi?id=706364
Remove grab window and cursor from the API, and just grab always
on the stage window with no cursor.
This is mainly to remove the X11 usage in the public API, in preparation
for implementing this in wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=705917
Using out-of-band notifications from the wayland protocol or from
X is racy, in that the client could ask for the new resources before
we have them.
Instead, with a signal, we are sure that when the client asks for
it, it will get the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=706382
Under X, we need to use XFixes to watch the cursor changing, while
on wayland, we're in charge of setting and painting the cursor.
MetaCursorTracker provides the abstraction layer for gnome-shell,
which can thus drop ShellXFixesCursor. In the future, it may grow
the ability to watch for pointer position too, especially if
CursorEvents are added to the next version of XInput2, and thus
it would also replace the PointerWatcher we use for gnome-shell's
magnifier.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
The value passed to XRRCrtcSetGamma must be allocated with
XRRAllocGamma (because it relies on the locations of green and blue),
otherwise garbage is sent on the wire.
https://bugzilla.gnome.org/show_bug.cgi?id=706231
We were relying on the XRandR events from the X server to update
the configuration, but we were calling meta_monitor_config_update_current()
immediately after, so the MonitorConfig would be updated with the
old configuration (and we would save that to disk!)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
