Allow scale-aware Xwayland clients to scale by an integer scale
themselves, instead of letting them render them at 1x scale and then
scaling up the texture, making it look blurry.
When monitor framebuffers are scaled, this special cases Xwayland and
sends output regions in a way that Xwayland think everything is N times
as large as the logical region, where N is the ceil of the max monitor
scale.
This is done by introducing a "stage" vs "protocol" coordinate space for
X11, where the "protocol" coordinate space is "stage" multiplied by a
scaling factor.
Xwayland thus will have its own "effective scale", sent via
wl_output.scale. The effective Xwayland scale is also used for the
internal MetaWaylandSurface scale internally, unless there is a viewport
dst size set on the same surface, in which case the scale is still set
to 1, to not interfere with wp_viewport semantics.
We're guarding this behind a new experimental feature
"xwayland-native-scaling", which can only come into effect when enabled
together with "scale-monitor-framebuffer".
[v2]:
Move stage_to_protocol/protocol_to_stage to generic window class.
This means parts that aren't aware of any windowing system specific
logic, only that coordinates originate from there for a given window,
can still get their coordinates properly handled.
In particular, this means coordinates from IBus that originates from the
client, can be scaled properly when that client is using X11.
Also make them properly introspected.
[v3]:
Split up coordinate transform API.
Make it one that takes a MtkRectangle, and another that takes a point.
This means the rounding strategy becames explicit when transforming a
point, while when it's a rectangle, it's still always "grow".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
This scale is currently a lie, it doesn't do anything. What it
represents is the current highest monitor scale, and will eventually be
used to, when configured to do so, scale X11 coordinates as well as
coordinates given to Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
We know let Xwayland set the RANDR names from the connectors. To stop
relying on layouts and coordinates to match the primary logical monitor,
instead use the connector name of the first monitor.
Also make the X11 client sanity checking check that the right X11 output
is primary as part of the monitor tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
With the next commits we'll introduce a new mode for scaling of Xwayland apps,
we'll want to put this mode behind an experimental setting though, so add
that setting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
This replaces the `legacy-ui-scaling-factor` entry in
`org.gnome.Mutter.DisplayConfig`, with the motivation being to no longer
expose X11 specific state via the monitor configuration API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
Hooks up the wayland protocol to the color state luminances. The color
state handles the default levels so we can just pass everything through
after we checked for all the error conditions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
Hiding it in debug logging was a little too hidden. Someone might want
to know why performance has degraded without having to restart in debug
mode hoping they can reproduce the issue.
Also remove an assertion that would issue spurious warnings. We should not
always expect IMPORT_STATUS_NONE (implying the first failure must be on
the first frame). Instead we might start with IMPORT_STATUS_OK for a number
of frames and then have a sporadic failure some time later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3928>
To expose it, run mutter/gnome-shell with `--debug-control` and then call
`./tools/debug-control.py --enable ColorManagementProtocol`, or set
`MUTTER_DEBUG_COLOR_MANAGEMENT_PROTOCOL=1`.
Co-authored-by: Joan Torres <joan.torres@suse.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3893>
Instead, get it from the context. See next commit
For ClutterText, we had to switch to using constructed
as the ClutterContext will be set for the ClutterActor in the
constructor phase
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3977>
Or, optionally, when the MUTTER_FRAMES_PLATFORM_LIBRARY env var is set
to "adwaita". For debugging purposes, it is possible to disable loading
any platform library with MUTTER_FRAMES_PLATFORM_LIBRARY set to "none".
Add the CSS class "ssd-frame" to the MetaFrame (i.e. GtkWindow)
instances
as that lets libadwaita pick the right style, and won't do anything for
non-Adwaita styles.
This patch is specially careful not to link against libadwaita.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2830
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3981>
Launching pipewire and wireplumber is racy, as there is an arbitrary
amount of time between pipewire is launched, and that the socket is
bound.
In order to eliminate this race, bind the pipewire sockets ourselves,
and launch pipewire (and wireplumber) when there is activity on the
socket. This is using the systemd method of doing socket activation,
which consists of passing the number of passed file descriptors via
$LISTEN_FDS, and the pid of the launchee via $LISTEN_PID.
The former is easy, just pass the file descriptors, but the former is
more tricky when using python, as executing code before exec() is poorly
supported and likely to be deprecated. To address this, socket
activation services are wrapped in a socket-launch.sh helper which sets
the $LISTEN_PID to itself before calling exec().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3973>
