It uses the org.gnome.SettingsDaemon.Power.Screen D-Bus API. Currently
brightness set if the proxy is not ready are ignored; whether the
brightness value should be cached and set once it appears or whether
color profiles should be reapplied is yet to be decided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
gsd-color provides this API, which exposes details about the night light
state. Currently, gsd-color also turns this state into CRTC gamma
changes, but this will eventually change, and this is a preparation for
this.
The proxy isn't yet used for anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
We now only enable DMA buffer based PipeWire screen casting if a
format/modifier has been negotiated. This practically means a consumer
is aware about what is needed, and we should not try to predict that it
uses the DMA buffer the right way (i.e. not mmap:ing directly).
However, in case we're not hardware accelerated, we never want to
attempt to use DMA buffer screen sharing, as we want to avoid
compositing into a DMA buffer on such hardware as doing so can be very
slow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2086>
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>
Adding a <dbus/> element containing a boolean (yes/no) determines
whether org.gnome.Mutter.DisplayConfig ApplyMonitorsConfig will be
callable. The state is also introspectable via the
ApplyMonitorsConfigAllowed property on the same interface.
For example
<monitors version="2">
<policy>
<dbus>no</dbus>
</policy>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The code style in the remote-desktop API is currently a mess.
While, the overall code style in mutter and gnome-remote-desktop is to
use spaces as tabulator, the remote-desktop API is mixed with both
spaces as tabulators and actual tabulators.
In addition to that, the code style in the XDG desktop portal APIs uses
spaces as tabulators as well.
To unify the code style, replace all actual tabulators with spaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2255>
The code style in the screencast API is currently a mess.
While, the overall code style in mutter and gnome-remote-desktop is to
use spaces as tabulator, the remote-desktop API is mixed with both
spaces as tabulators and actual tabulators.
In addition to that, the code style in the XDG desktop portal APIs uses
spaces as tabulators as well.
To unify the code style, replace all actual tabulators with spaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2255>
The only currently known issue with allocating scanout buffers with
modifiers is memory constraints in multi head setups. Heuristics for
handling that are not implemented, but since it doesn't apply to
anything but i915, remove the other drivers from the deny list.
The other drivers had modifiers disabled to marginally increase the
chance of becoming scanout-able when allocated by Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
Defining valid values makes
1. changing settings less error prone
2. sure they are discoverable.
This does reset the values once on update, but fortunately does *not*
change the way to set the values. Thus e.g. enabling fractional scaling
via terminal command still works as before and internet guides stay valid.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1961>
Virtual Kernel Mode Setting (vkms) is a virtual /dev/dri/card* device
not backed by any actual hardware. It's intended for testing purposes,
e.g. to run tests suites with a reproducable setup, or in continuous
integration pipelines.
Currently mutter don't have any tests that can run on top of vkms, but
will eventually get that. To prepare for the ability to do that, and
having said kernel module loaded without causing wierd issues with any
active session, add an udev rule that tells mutter to ignore any vkms
device.
Otherwise, when vkms is loaded, mutter would detect it, assume it's a
regular monitor, configure it as such, thus add a region of the stage
that ends up nowhere, which isn't very helpful. It might also conflict
with running actual tests that need to interact with vkms if the active
session has taken control of it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1740>
Users who customized their workspace shortcuts before updating to
GNOME 40 are experiencing troubles when trying to use the same
keybinding for the horizontal shortcuts, because of hidden conflicts
with the vertical ones.
We can address this by registering the old shortcuts with Settings
without showing them in the UI, so that they are taken into account
by Settings' conflict resolution.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1740
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1814>
Lets wait until we have better ways to unredirect client buffers before
we start enabling KMS modifiers for amdgpu and nouveau; we end up with
mismatch between client buffer modifiers and primary plane modifier,
which right now needs to be the same for unredirection.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1792>
The intel DRM driver is known for not being able to handle multi head
setups when KMS modifiers are enabled, due to the implicitly selected
modifiers, while being more suitable for single head setups, cause
bandwidth issues when a certain number of monitor times resolution and
refresh rate is configured.
We don't yet support automatically finding a combination of modifiers
that work, and have because of this disabled KMS modifiers unless the
driver actually needs it.
Lets flip this configuration the other way around, changing the current
udev rule to decide wen to *disable* KMS modifier support, as it so that
only the Intel driver has this problem, while on the other hand, there
several drivers that requires modifiers to function at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1792>
Closing automatically Xwayland once all relevant X11 clients are gone is
inherently racy, if a new client comes along right at the time we're
killing Xwayland.
Fixing the possible race conditions between mutter, Xwayland and the X11
clients may take some time.
Meanwhile, make that an experimental feature "autoclose-xwayland".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1673>
The X server, including Xwayland, can be compiled with different X11
extensions enabled at build time.
When an X11 extension is built in the X server, it's usually also
enabled at run time. Users can chose to disable those extensions at run
time using the X server command line option "-extension".
However, in the case of Xwayland, it is spawned automatically by the
Wayland compositor, and the command line options are not configurable
by users.
Add a new setting to disable a selected set of X extension in Xwayland
at startup, without needing to rebuild Xwayland.
Of course, if Xwayland is not built with a given extension support in
the first place (which is the default for the security extension for
example), that option has no effect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1405
The check-alive feature is there for the user to be able to terminate
frozen applications more easily. However, sometimes applications are
implemented in a way where they fail to be reply to ping requests in a
timely manner, resulting in that, to the compositor, they are
indistinguishable from clients that have frozen indefinitely.
When using an application that has these issues, the GUI showed in
response to the failure to respond to ping requests can become annoying,
as it disrupts the visual presentation of the application.
To allow users to work-around these issues, add a setting allowing them
to configure the timeout waited until an application is considered
frozen, or disabling the check completely.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1080
To emulate X11 grabs, mutter as a Wayland compositor would disable its
own keyboard shortcuts and when the X11 window is an override redirect
window (which never receives focus), it also forces keyboard focus onto
that X11 O-R window so that all keyboard events are routed to the
window, just like an X11 server would.
But that's a bit of a “all-or-nothing” approach which prevents
applications that would legitimately grab the keyboard under X11 (like
virtual machine viewers) to work by default.
Change “xwayland-allow-grabs” to control whether the keyboard focus
should be locked onto override redirect windows in case of an X11 grab.
For stringent needs, careful users can still use the blacklisting
feature (i.e. a list containing “!*”) to prevent grabs from any X11
applications to affect other Wayland native applications.
https://gitlab.gnome.org/GNOME/mutter/issues/597
I saw Meson fade from the sky
On the wind I heard a sigh
As snowflakes cover fallen Makefiles
I will say this last goodbye
Meson is now coming
So ends Autotools days
Future is now coming
And we must away
Over Python and without Bashisms
Through lands where never Meson touched
By silver streams that run down to the Sea
Under parsers, beneath old legacy
Over snow one winter’s morn
I turned at last to paths that lead home
And though where the road then takes me
I cannot tell
We came all this way
But now comes the day
To bid you farewell
Many places I have been
Many sorrows I have seen
But I don’t regret
Nor will I forget
All Makefiles that took that road with me
I bid you all a very fond farewell.
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
GTK+ doesn't support shading of client-side decorated windows, and likely
never will (not least because shading is conceptually questionable if the
app customizes the titlebar), and neither do other CSD implementations like
Chromium's. A shortcut that only works with a decreasing number of windows
is more confusing than helpful, so don't expose it.
https://bugzilla.gnome.org/show_bug.cgi?id=645460
