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>
This uses the luminance levels of the color states to anchor the white
of content instead of hard-coding the levels.
This also starts using uniforms for parts of the mapping which means we
don't have to generate and compile a shader when the luminance levels
change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
They represent the minimum and maximum luminance levels of the primary
color volume and the reference luminance level (reference white, SDR
white, ...) in the reference viewing environment.
They help anchoring the white level, optionally help with preserving the
dynamic range and help with adjusting from a "dark" to a "bright"
viewing environment.
The values have defaults which depend on the transfer characteristics.
This reflects the wayland color management protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
Actions might get detached sometime during event processing,
at a time that the stage did already prepare an emission chain
holding references to the actions and actors that need to handle
events. This means actions might become detached, but still handle
the incoming event, or possible crossing events generated in-place
when the actor becomes unparented.
Avoid this situation, by skipping event handling on actions that
went detached, we will just instruct to continue event processing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3988>
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>
