When using Xwayland-on-demand (default), if the (experimental) autoclose
features is enabled, we can rely on Xwayland's auto-terminate feature
instead of explicitly killing the Xwayland process.
With it, gone is the mechanism that was added to check the X11 clients
connected and their executable to check whether we can (safely) kill
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
The connection to the Xserver for the X11 window manager part of mutter
even on Wayland may prevent the Xserver from shutting down.
Currently, what mutter does is to check the X11 clients still connected
to Xwayland using the XRes extension, with a list of X11 clients that
can be safely ignored (typically the GNOME XSettings daemon, the IBus
daemon, pulseaudio and even mutter window manager itself).
When there is just those known clients remaining, mutter would kill
Xwayland automatically.
But that's racy, because between the time mutter checks with Xwayland
the remaining clients and the time it actually kills the process, a new
X11 client might have come along and won't be able to connect to
Xwayland that mutter is just about to kill.
Because of that, the feature “autoclose-xwayland” is marked as an
experimental feature in mutter and not enabled by default.
Thankfully, the Xserver has all it takes to manage that already, and
is even capable of terminating itself once all X11 clients are gone (the
-terminate option on the command line).
With XFixes version 6, the X11 clients can declare themselves
"terminatable", so that the Xserver could simply ignore those X11
clients when checking the remaining clients and terminate itself
automatically.
Use that mechanism to declare mutter's own connection to the Xserver as
"terminatable" when Xwayland is started on demand so that it won't hold
Xwayland alive for the sole purpose of mutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
gtk-doc support was taken out about six years ago, but never replaced.
Add support for the newer gi-docgen, which should hopefully encourage
both C and GJS users of these libraries to improve the reference.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2248>
These will be skipped by default, but can be run from a TTY for easier
debugging by doing:
dbus-run-session -- meson test -C build --suite mutter/native/tty --setup plain
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This commit makes it possible to run test executables in a test
environment constructed of a virtual machine running the Linux kernel
with the virtual KMS driver enabled, and a mocked system environment
using meta-dbus-runner.py/python-dbusmock.
The qemu machine is configured to use 256M of memory, as the default
128M was not enough for the tests to pass.
Using qemu is also only made possible on x86_64; more changes are needed
for it to be runnable on aarch64, so add a warning if it was enabled on
any other architecture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
Since the CI pipeline now runs `meson dist` which includes a test
for an up-to-date NEWS entry, post-branch/release version bumps
have become unwieldy.
It's still useful to increase the API version right after branching
though, so return to bumping it manually and do so now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2053>
Easily seeing the buildtype and debug status can be quite useful.
Gnome-Shell already has it.
And while on it, add a 'Directories' section for already existing
entries.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2044>
I don't think this ever happened to me, but it can't hurt enforcing
that every release has a corresponding NEWS entry.
(The script has been copied from Polari, thus the metainfo support)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1980>
Create a test system bus and use it to run all the tests, add a mock
SensorsProxy (via dbusmock template) server that implements the
net.hadess.SensorProxy interface.
To make testing easier, the service is created on request of a proxy for
it, whose lifetime controls the mock service lifetime as well.
This is done using a further mock service that is used to manage the
others, using python-dbusmock to simplify the handling.
Add basic tests for the orientation manager.
As per the usage dbusmock, we're now launching all the tests under such
wrapper, so that local dbus environment won't ever considered, and
there's no risk that it may affect the tests results both locally and in
CI.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
To utilize the API provided by libsystemd it would be better to
create a separate HAVE_LIBSYSTEMD configuration option instead of
having to rely on HAVE_NATIVE_BACKEND.
For now this will be utilized for getting the control group of a
MetaWindow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1960>
Tests that creating and starting a virtual screen cast monitor works,
and that at least one one buffer is processed.
Currently the content of the buffer isn't checked more than it can be
mmap():ed. Only MemFd buffers are tested for for now, as DMA buffers
would need a surfaceless EGL context to check properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The 0.3.21 release includes busy buffers, which are a requirement
for us to switch to cogl_framebuffer_flush() in the next commit.
Bump pipewire dependency to 0.3.21, and adjust CI to build it from
the corresponding tag.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1701>
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>
Some GSettings schemas moved from g-s-d to gsettings-desktop-schemas
in g-s-d 40.alpha. 40.alpha.1 didn't include the corresponding
adjustment, so do a quick follow-up release to not abort on startup
with the latest g-s-d release.
I messed up and released 40.alpha at the same time as 3.38.2, when it's
supposed to be in January. In order to re-align with the schedule, change
the upcoming version to 40.alpha2 so we don't have to skip a release and
will be back on track in time of 40.beta.
Xwayland in its main development branch now provides a pkg-config file
which can be used to determine Xwayland installation path and various
options enabled at build time.
Change mutter build system to optionally use that mechanism if
available. If not (as with Xwayland from the current stable branch),
keep the fallback mechanisms (basically search for the Xwayland and parse
its command line options to determine if initfd is available).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1635>
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
