Current Xwayland has marked the command line option "-listen" as
deprecated in favor of "-listenfd".

Use the pkg-config variable "have_listenfd" (if available) from Xwayland
to determine if we should use that option, to avoid a deprecation
warning when spawning Xwayland.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1682>

Currently, mutter checks for the presence of X11 windows to decide
whether or not Xwayland can be terminated, when Xwayland is started on
demand.

Unfortunately, not all X11 clients will map a window all the time, an
X11 client may keep the X11 connection opened after closing all its
windows. In that case, we may terminate Xwayland while there are some
X11 client connected still, and terminating Xwayland will also kill
those X11 clients.

To avoid that issue, check the X11 clients actually connected using the
XRes extension. The XRes extension provides the PID of the (local) X11
clients connected to the Xserver, so we need to match that against the
actual executable names, and compare with a list of known executables
that we can safely ignore, such as ibus-x11 or gsd-xsettings.

We also check against our own executable name, considering that the X11
window manager is also an X11 client connected to the Xserver.

Also, XRes returning the PID of local clients only is not a problem
considering that Xwayland does not listen to remote connections.
However, if the user spawns a client remotely on another system using
ssh tunneling (ssh -X), only clients which actually map a window will
be accounted for.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1537
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1671>

If this call is available, we can turn libX11 IO errors (fatal by definition)
into something we can recover from. Try to dispose all X11 resources and close
the display instead, so the compositor can survive the event.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1447

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1410

Add MetaAnonymousFile, an abstraction around anonymous read-only files.
Files can be created by calling meta_anonymous_file_new(), passing the
data of the file. Subsequent calls to meta_anonymous_file_open_fd()
return a fd that's ready to be sent over the socket.

When mapmode is META_ANONYMOUS_FILE_MAPMODE_PRIVATE the fd is only
guaranteed to be mmap-able readonly with MAP_PRIVATE but does not
require duplicating the file for each resource when memfd_create is
available. META_ANONYMOUS_FILE_MAPMODE_SHARED may be used when the
client must be able to map the file with MAP_SHARED but it also means
that the file has to be duplicated even when memfd_create is available.

Pretty much all of this code was written for weston by Sebastian Wick,
see https://gitlab.freedesktop.org/wayland/weston/merge_requests/240.

Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>

https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012

This is used by GDK and the X11 bits, but may also be used for
other initialization services we might need to run along with
Xwayland initialization.

However, as the -initfd argument in Xwayland is a fairly new
feature, add some meson build-time checks so that the feature
is handled transparently while allowing to explicitly set/unset
it.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/945

Otherwise we won't get core dumps if the launching binary has
capabilities set.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/811

The include <sys/random.h> was added to glibc-2.25, previously was
<linux/random.h>.

Adjust meson build and code to accomodate both.

Fixes: a8984a81c "xwayland: Generate a Xauth file and pass this to
                  Xwayland when starting it"

https://gitlab.gnome.org/GNOME/mutter/merge_requests/633

It fits better the name of the build flag. Cogl still uses
HAVE_TRACING since profiler is already used by it.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/603

Add the ability to add tracing instrumentation to the code. When
enabled, trace entries will generate a file with timing information
that will be processable by sysprof for generating visualization of
traces over time.

While enabled by default at compile time, it is possible to disable the
expansion of the macros completely by passing --disable-tracing to
./configure.

Tracing is so far only actually done if actually enabled on explicitly
specified threads.

This will be used by Mutter passing the write end of a pipe, where the
read end is sent to Sysprof itself via the D-Bus method 'Capture()'.

By passing that, we have to detect EPIPE that is sent when Sysprof stops
recording. Fortunately, we already ignore the signal at meta_init(), so
no need to add a custom signal handler.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/197