We currently use the "ssd" style class instead of "csd", so themes
can avoid adding a window shadow to windows that already got a shadow
from the compositor. Now that we no longer add a shadow to regular
windows, we should ask for the appropriate style.

We can only honor this properly in the MUTTER_STAGE_VIEWS=1 case. When using
the legacy view, software implemented transforms are only exposed if there is
only one output, as we can only transform the entire stage there.

All the upper layers are prepared for multiple onscreen cursors, but
this. All MetaCursorRenderers created would poke the same internal
MetaOverlay in the stage.

This will lead to multiple cursor renderers resorting to the "SW"
rendering paths (as it can be seen with tablet support) to reuse the
same overlay, thus leading to flickering when a different
MetaCursorRenderer takes over the overlay.

Fix this by allowing per-cursor-renderer overlays, their lifetime
is attached to the cursor renderer, so is expected to be tear down
if the relevant device (eg. tablet) disappears.

As per the spec. wl_pointer.axis_source determines the current source of
scroll events, wl_pointer.axis_stop determines when there's no further
scroll events on any axis (Which Clutter sends as dx/dy=0 events).
wl_pointer.axis_frame marks the end of a series of axis_* events.

v2: Updated to v4 of the protocol spec by
Peter Hutterer <peter.hutterer@who-t.net>
v3: Update to use Clutter API

The old requirement that multiple MetaBackgroundActor objects be
layered on top of each to produce blended backgrounds resulted in
extremely inefficient drawing since the entire framebuffer had
to be read and written multiple times.

* Replace the MetaBackground ClutterContent with a plain GObject
that serves to hold the background parameters and prerender
textures to be used to draw the background. It handles
colors, gradients, and blended images, but does not handle
vignetting

* Add vignetting to MetaBackgroundActor directly.

* Add MetaBackgroundImage and MetaBackgroundImageCache to allow
multiple MetaBackground objects to share the same images

By removing the usage of ClutterContent, the following optimizations
were easy to add:

Blending is turned off when the actor is fully opaque
Nearest-neighbour filtering is used when drawing 1:1

The GLSL vignette code is slightly improved to use a vertex shader
snippet for computing the texture coordinate => position in actor
mapping.

We might be asked to not display the cursor ourselves but we should
still emit cursor-changed signals and hand out the correct sprite and
hot point information when asked so that consumers can still draw an
updated cursor themselves.

1) We need to select for shape events
2) For decorated windows, we don't want to apply any input
shape, because the frame is always rectangular and eats
all the input
3) For undecorated windows, the "has input shape" check is
wrong if the window has a bounding shape but not an input
shape

The rendering logic before was somewhat complex. We had three independent
cases to take into account when doing rendering:

* X11 compositor. In this case, we're a traditional X11 compositor,
not a Wayland compositor. We use XCompositeNameWindowPixmap to get
the backing pixmap for the window, and deal with the COMPOSITE
extension messiness.

In this case, meta_is_wayland_compositor() is FALSE.

* Wayland clients. In this case, we're a Wayland compositor managing
Wayland surfaces. The rendering for this is fairly straightforward,
as Cogl handles most of the complexity with EGL and SHM buffers...
Wayland clients give us the input and opaque regions through
wl_surface.

In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND.

* XWayland clients. In this case, we're a Wayland compositor, like
above, and XWayland hands us Wayland surfaces. XWayland handles
the COMPOSITE extension messiness for us, and hands us a buffer
like any other Wayland client. We have to fetch the input and
opaque regions from the X11 window ourselves.

In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11.

We now split the rendering logic into two subclasses, which are:

* MetaSurfaceActorX11, which handles the X11 compositor case, in that
it uses XCompositeNameWindowPixmap to get the backing pixmap, and
deal with all the COMPOSITE extension messiness.

* MetaSurfaceActorWayland, which handles the Wayland compositor case
for both native Wayland clients and XWayland clients. XWayland handles
COMPOSITE for us, and handles pushing a surface over through the
xf86-video-wayland DDX.

Frame sync is still in MetaWindowActor, as it needs to work for both the
X11 compositor and XWayland client cases. When Wayland's video display
protocol lands, this will need to be significantly overhauled, as it would
have to work for any wl_surface, including subsurfaces, so we would need
surface-level discretion.

When the user maximized a CSD window, this is the order of operations
that happens:

1. The CSD application sends us a _NET_WM_STATE client message telling
us to add the _NET_WM_MAXIMIZED_VERT/HORZ state.

2. We respond by setting _NET_WM_STATE on the window and resizing the
window. Windows are positioned according to the visible borders of
the window, so since _GTK_FRAME_EXTENTS has not been updated yet to
reflect the border/padding of the window state, the borders are wrong.

3. GTK+ gets the _NET_WM_STATE event, updates its state, and then sets
new theme properties, including _GTK_FRAME_EXTENTS.

4. mutter sees that _GTK_FRAME_EXTENTS has been updated, and repositions
the window to where it should be.

This means that the user sees the borders "flicker" for a half-second while
the maximization state is in limbo. Trying to make this resize operation
atomic is a foregone conclusion under X11, so to solve this, we're going to
make two changes to our _GTK_FRAME_EXTENTS protocol:

1. _GTK_FRAME_EXTENTS now reflects the "normal" borders, always. This
means that _GTK_FRAME_EXTENTS should not change at runtime unless the
theme changes.

2. mutter will only respect _GTK_FRAME_EXTENTS in places where the user
expects to see a shadow. This means that mutter will hardcode the
extents to 0 when the window is maximized. If the window is tiled-left,
then all extents will be 0, except for the shadow on the right hand
side, and vice versa for the tiled-right state.

Some clients, like on-screen keyboards, don't want their windows to be
activated on click, as that would steal focus from the window they're
trying to send events to. They do this by setting the Input Hint in
WM_HINTS to be FALSE, along with not specifying WM_TAKE_FOCUS in their
WM_PROTOCOLS.

However, in this case, when a window tries to get focus in this scenario,
we focus the frame so that a11y and key navigation works properly.
Both policies aren't acceptable -- we can't make OSK steal focus from
windows on click, and we can't make an OSK un-Alt-Tabbable-to.

To solve this, split meta_window_focus() into two different focus policies:

* meta_window_focus_implicitly() should be called on pointer click or
focus-follows-mouse or similar cases where we may not want to forcibly
set focus for clients that don't want it.

* meta_window_focus_explicitly() should be called by pagers, like
the gnome-shell overview, or Alt-Tab. In this case, most of the existing
clients are using meta_window_activate(), so simply adapting that so
it calls meta_window_focus_explicitly() should be enough.

In order to see all Clutter events, Mutter was previously installing a
signal handler on the ‘captured-event’ signal on the stage and
additionally using a signal emission hook to cope with grabs. This
changes it to use the new clutter_event_add_filter API so that we can
avoid the signal emission hook hack.

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.

Once mutter is started from weston-launch on its own VT, there is
no way to change VT again (for example to actually start an application),
because the keyboard is put in raw mode.
So introduce some keybindings mimicking the standard X ones (Ctrl+Alt+Fn)
that switch the VT manually when activated.

MonitorXrandr: follow the right order in applying the new configuration

Author:
Giovanni Campagna
Author Date:
2013-08-16 17:02:57 UTC

MonitorXrandr: follow the right order in applying the new configuration

First disable CRTCs that should be off in the new configuration,
then resize the framebuffer, then enable the new CRTCs.
If we don't do that, and we're making the screen smaller, X complains
with a BadMatch.

MetaWaylandSeat: reset pointer focus always when it might be different

Author:
Giovanni Campagna
Author Date:
2013-08-14 14:29:09 UTC

MetaWaylandSeat: reset pointer focus always when it might be different

It can happen because of a grab that the current surface changes
but the focus doesn't. Later on, when the grab ends, we would keep
the previous focus until the user goes out of the window and
back in again.

gnome-shell needs to know whether the stage window is focused so
it can synchronize between stage window focus and Clutter key actor
focus. Track all X windows, even those without MetaWindows, when
tracking the focus window, and add a compositor-level API to determine
when the stage is focused.

XUngrabKey() doesn't work for XI2 grabs and XI2 doesn't provide API
with similar functionality. As such, we have to refactor the code a
bit to be able to call XIUngrabKeycode() for each key binding, then
reload keybindings and finally grab the new ones.

In different places we checked the grab op differently when determing
whether we are using _NET_WM_SYNC_REQUEST. This was somewhat covered
up previously by the fact that we only had a sync alarm when using
_NET_WM_SYNC_REQUEST, but that is no longer the case, so consistently
use meta_grab_op_is_resizing() everywhere.

Any number of touches >= 3 starts a drag operation, but the
window jumped around as new touches joined. So recalculate
the touch drag area/hotspot and tiling mode as expected
as soon as touches enter/leave the drag op.

Otherwise, if the user had moved the windows around using a mouse,
they can not be moved beyond the top edge of the primary monitor when
the tray needs to be brought up, . This is because
constrain_titlebar_visible looks at grab_frame_action and thinks that
the movement is being caused by the user trying to move the windows up
by grabbing the frame.

Any number of touches >= 3 starts a drag operation, but the
window jumped around as new touches joined. So recalculate
the touch drag area/hotspot and tiling mode as expected
as soon as touches enter/leave the drag op.

Since the stack passed to the compositor now accurately reflects
the X stacking order, we need to treat hidden windows (which are
at the bottom of the X stacking order) specially - when the
compositor stacking order is synced, try to keep animating hidden
actors in their old positions in the stack.