hack autogen to allow automake 1.13
Track the X Shape input region and use it for picking

We now track whether a window has an input shape specified via the X
Shape extension. Intersecting that with the bounding shape (as required
by the X Shape extension) we use the resulting rectangles to paint
window silhouettes when picking. As well as improving the correctness of
picking this should also be much more efficient because typically when
only picking solid rectangles then the need to actually render and issue
a read_pixels request can be optimized away and instead the picking is
done on the cpu.
configure: Adds wayland config options

This adds a --enable-wayland configure option to enable building mutter
as a hybrid X and Wayland compositor. By default the option is disabled.
If enabled HAVE_WAYLAND is defined for C code and as an automake
conditional.

In addition a --with-wayland-protocols option has been added since
wayland support will depend on the xserver.xml extension protocol that's
currently part of the Weston project which we need the location of.
configure: Adds --with-xwayland-path option

This adds a --with-xwayland-path configure option that can be used to
specify the absolute path of a headless X server binary supporting
the wayland xserver protocol.
Adds a --nested option

This adds a --nested option to request that mutter no longer run as a
classic X compositor with an output window mapped on the X Composite
Overlay Window and also not assume it is running directly under X.

The intention is that in this mode Mutter will itself launch a headless
X server and display output will be handled by Clutter and Cogl. This
will enable running Mutter nested as an application within an X session.

This patch introduces the internal idea that mutter is running as a
"display server" as a means to condition the way mutter operates in
various ways throughout the code base.

Later we also expect to add a --kms option as another way of enabling
this display server mode that will assume full control of the display
hardware instead of running as a nested application.
wayland: Adds basic hybrid X + Wayland support

This adds support for running mutter as a hybrid X and Wayland
compositor. It runs a headless XWayland server for X applications
that presents wayland surfaces back to mutter which mutter can then
composite.

This aims to not break Mutter's existing support for the traditional X
compositing model which means a single build of Mutter can be
distributed supporting the traditional model and the new Wayland based
compositing model.

TODO: although building with --disable-wayland has at least been tested,
I still haven't actually verified that running as a traditional
compositor isn't broken currently.

At this point no input is supported

Note: This patch is still a work in progress

Additional authors:
  Neil Roberts <neil@linux.intel.com>
  Rico Tzschichholz.
Add support for stacking X and Wayland windows together

This breaks down the assumptions in stack-tracker.c and stack.c that
Mutter is only stacking X windows.

The stack tracker now tracks windows using a MetaStackWindow structure
which is a union with a type member so that X windows can be
distinguished from Wayland windows.

Some notable changes are:

Queued stack tracker operations that affect Wayland windows will not be
associated with an X serial number.

If an operation only affects a Wayland window and there are no queued
stack tracker operations ("unvalidated predictions") then the operation
is applied immediately since there is no server involved with changing
the stacking for Wayland windows.

The stack tracker can no longer respond to X events by turning them into
stack operations and discarding the predicted operations made prior to
that event because operations based on X events don't know anything
about the stacking of Wayland windows.

Instead of discarding old predictions the new approach is to trust the
predictions but whenever we receive an event from the server that
affects stacking we cross-reference with the predicted stack and check
for consistency. So e.g. if we have an event that says ADD window A then
we apply the predictions (up to the serial for that event) and verify
the predicted state includes a window A. Similarly if an event says
RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for
that event) and verify that window B is above C.

If we ever receive spurious stacking events (with a serial older than we
would expect) or find an inconsistency (some things aren't possible to
predict from the compositor) then we hit a re-synchronization code-path
that will query the X server for the full stacking order and then use
that stack to walk through our combined stack and force the X windows to
match the just queried stack but avoiding disrupting the relative
stacking of Wayland windows. This will be relatively expensive but
shouldn't be hit for compositor initiated restacking operations where
our predictions should be accurate.

The code in core/stack.c that deals with synchronizing the window stack
with the X server had to be updated quite heavily. In general the patch
avoids changing the fundamental approach being used but most of the code
did need some amount of re-factoring to consider what re-stacking
operations actually involve X or not and when we need to restack X
windows we sometimes need to search for a suitable X sibling to restack
relative too since the closest siblings may be Wayland windows.
wayland: Add basic input support

This copies the basic input support from the Clayland demo compositor.
It adds a basic wl_seat implementation which can convert Clutter mouse
events to Wayland events. For this to work all of the wayland surface
actors need to be made reactive.

The wayland keyboard input focus surface is updated whenever Mutter
sees a FocusIn event so that it will stay in synch with whatever
surface Mutter wants as the focus. Wayland surfaces don't get this
event so for now it will just give them focus whenever they are
clicked as a hack to test the code.
wayland: Add an actor for the cursor

When running Mutter under Cogl's KMS backend no cursor will be
provided so instead this makes it so the cursor will be painted as a
CoglTexture that gets moved in response to mouse motion events. The
painting is done in a subclass of ClutterStage so that we can
guarantee that the cursor will be painted on top of everything else.

This patch adds support for the set_cursor method on the pointer
interface so that clients can change the cursor image.

The set_pointer method sets a surface and a hotspot position to use
for the cursor image. The surface's buffer is converted to a
CoglTexture and attached to a pipeline to paint directly via Cogl. If
a new buffer is attached to the surface the image will be updated. The
cursor reverts back to the default image whenever to the pointer focus
is moved off of any surface.

The image for the pointer is taken from X. It gets installed into
a fixed data location for mutter.
wayland: support left click to raise wayland surfaces

This adds support for raising wayland surfaces when clicked with the
left mouse button.
wayland: implement shell surface move interface

This implements the shell surface move interface so now it's possible to
use the mouse to interactively move wayland based windows around the
screen.
squash: Fix the logic for falling back to a non-abstract unix socket

This should be squashed into the commit:
“wayland: Adds basic hybrid X + Wayland support”

Based on this clayland commit:
https://github.com/clutter-project/clayland/commit/be1bc97ca4374ca9
squash: Update because wl_shm_buffer is no longer a wl_buffer (1)

This should be squashed into the commit:
“wayland: Adds basic hybrid X + Wayland support”

Based on this clayland commit:
https://github.com/clutter-project/clayland/commit/d08f31d22ad63c
squash: Update because wl_shm_buffer is no longer a wl_buffer (2)

This should be squashed into the commit:
“wayland: Add an actor for the cursor”

Based on this clayland commit:
https://github.com/clutter-project/clayland/commit/d08f31d22ad63c
squash: Prepare for wl_resource becoming opaque (1)

wl_client_add_resource is deprecated an wl_resource will soon become
opaque.

This should be squashed into the commit:
“wayland: Adds basic hybrid X + Wayland support”

Based on this clayland commit:
https://github.com/clutter-project/clayland/commit/b8e5fe1c9920a9104
squash: Prepare for wl_resource becoming opaque (2)

wl_client_add_resource is deprecated an wl_resource will soon become
opaque.

This should be squashed into the commit:
“wayland: Add basic input support”

Based on this clayland commit:
https://github.com/clutter-project/clayland/commit/b8e5fe1c9920a9104
Don't handle SIGCHILD ourselves

Doing so is a recipe for disaster in a glib application. Instead,
you're expected to use GChildWatch.
Also, while we're there let's replace fork/exec with a proper API.
wayland: don't use deprecated stuff

The new resource creation functions allow us to specify the version
explicitly, which is necessary to avoid gtk+ calling methods we
don't implement yet.
core: don't follow any wayland paths if not running as a wl compositor

If --display-server is not passed, ignore all wayland code paths
to behave like regular mutter.
wayland: add TTY and DRM master management through weston-launch

To run mutter as a display server, one needs to acquire and
release the DRM master, which is only possible for root, so
we take advantage of weston-launch, a small setuid helper binary
written for the weston project.