This looks at the color state it got from the actor on construction, and
the target color state from the paint context and generates (and caches)
color aware pipelines used for painting. One of the purposes here is for
mixing SDR and HDR content and painting to a HDR monitor. If HDR (or
optical blending) isn't activated, the produced shaders will be
equivalent to what we had before.
Also add some names to the piplines, as this helps identifying what
pipeline source is associated with what pipeline.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
In some of the places we need more context than just the CoglContext, so
prepare for that by passing around the paint context, which carries
this, everywhere instead. It won't be needed everywhere, but lets stay
consistent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
Color aware rendering needs shaders / pipelines that adapt to what
output they render to. For example if we want to render to a linear
BT.2020 intermediate framebuffer on one monitor, and a non-linear sRGB
direct target buffer on another, the shader for the same paint node or
content will depend on where they are going to be presented.
In order to help keeping track of what shader should target what
monitor, without having to regenerate them each time, introduce a
pipeline cache that knows how to handle differentiating between
transforming between different color state.
The cache is meant to handle caches for multiple pipeline users, where
each user might potentially want to keep track of multiple pipelines
itself. Lookup should be O(1), and in order to achieve this, separate
the cache into 3 levels.
The first level is the "pipeline group", where e.g. a ClutterContent
type allocates a group where it can store its pipelines. Each group has
a fixed number of "slots" where it can store a pipeline. Each slot has a
hash table where the key is derived from a color state transform, and
where the value is a CoglPipeline where the thame color state
transformation is expected to be handled.
A content will when painting know about its own color state, and the
target state it should render into, retrieve a cached pipeline for the
correct transform, or if the cache didn't have it, generate it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
Allow compositing in a linear color space and do so either when forcing
it via the debug controls D-Bus API, or when the experimental HDR mode
is enabled.
This relies on paint nodes etc to actually transform everything into the
linear target color space, which isn't done yet, so enabling it right
now will cause a broken result. Yet, introduce this now, so that
painting can be fixed piece by piece.
Linear blending is automatically enabled on monitors where HDR is
enabled, as this makes it possible to use an linear color space when
blending content from different color spaces with different transfer
functions.
Linear blending requires extra precision, i.e. 16 bit per channel
in the intermediate buffer due how the values are distributed,
so only enable the experimental HDR mode if the Cogl context supports
half float formats.
By default, no intermadiate linear offscreen framebuffer is used.
To test, do e.g.
./tools/debug-control.py --toggle ForceLinearBlending
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
The initial target color state is the color state of the stage view
being painted to. If we're painting to an arbitrary framebuffer, it's
currently hard coded to sRGB/electrical.
The content color state is not set on construction, but when starting to
paint, it's set to the color state of the stage itself. Whenever an
actor is painted, it'll set the color state to the color state of
itself. The intention is that offscreen rendering pushes a target color
state that causes painting to it to not necessarily be in the stage view
color state.
Pass color state with offscreen framebuffer, as this avoids hard coding
sRGB in the lower level bits of paint contexts. It's still practically
hard coded, only that it's derived from somewhere else (e.g. the stage
or window actor).
Nothing is actually using this yet, but will eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
An unknown color space isn't very useful to have, as there is not very
actionable what to do with it. Rename it to 'default'. Later it'll be
used to an implicit color space, which in practice will be treated as
sRGB.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
g_unix_fd_list_append() duplicates the provided fd. If that fails, it
returns -1 as fd index and sets - if provided - the passed GError
accordingly.
However, currently, mutter does not check the return value (the fd index
of the appended fd) and thus passes an invalid fd list via dbus to the
remote desktop session user.
Fix this error by also checking the fd index. If the fd index is invalid
(< 0), simply pass the error message of the g_unix_fd_list_append() call
to the caller.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3871>
This reverts commit a3082b8eb35fffbb4c23f7794414a58c14708177.
We don't find the VKMS device with this commit because it is on seat0
and not on META_BACKEND_TEST_INPUT_SEAT.
The other way around, i.e. returning seat0 in all cases also doesn't
work because *something* hangs if the default seat referrs to the real
seat0 instead of the nonesense META_BACKEND_TEST_INPUT_SEAT.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3869>
mktemp can create a tempfile relative to a directory passed in via -p.
It also uses the $TMPDIR variable for the same purpose. When the
template is specified via -t, $TMPDIR takes precedence over -p. When the
template is specified via a positional argument, -p takes precedence.
Since fec38819acc9a95a7ed18b8f103fb5d9a59c3c41 $TMPDIR is set via the
dbus runner which took precedence.
virtme-ng doesn't seem to share /tmp with the host system which results
in the exit status from the test in the VM not propagating back to the
test harness.
Fix that by making sure we always create the tempfile for the result in
the build directory.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3867>
Fixes error building against libdrm >= 2.4.122:
../src/backends/native/meta-kms-plane.c:67:8: error: redefinition of ‘struct drm_plane_size_hint’
67 | struct drm_plane_size_hint {
| ^~~~~~~~~~~~~~~~~~~
In file included from /usr/local/include/libdrm/drm.h:1025,
from /usr/local/include/xf86drm.h:40,
from ../src/backends/native/meta-kms-plane-private.h:20,
from ../src/backends/native/meta-kms-plane.c:21:
/usr/local/include/libdrm/drm_mode.h:866:8: note: originally defined here
866 | struct drm_plane_size_hint {
| ^~~~~~~~~~~~~~~~~~~
Suggested by Jonas Ådahl.
v2:
* Use has_type. (Sebastian Wick)
v3: (jadahl)
* Bump meson requirement to 1.3.0 for compiler.has_type()
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3556
Fixes: 0ca933baecf0 ("backend/native: Adds support for SIZE_HINTS Cursor Plane Property")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3848>
This code is called from handlers connected to signals of a
MetaWindow. It cannot happen that the window will end up NULL
in these, so exchange with a g_assert() as we in fact expect
it to be non-NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3860>
We cannot use a function with the same signature for signals with different
arguments, if we want to rely on the user data parameter. Separate into
two signal handlers calling the same function inside.
Fixes: b9ba34ac6f ("wayland/activation: Fix signal callback signature")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3860>
The two dialog creation virtual functions returned by these functions have to
be unreferenced by the caller (and are actually unreferenced in other places in
the code).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3790>
This gives greater control to the callers on the place where a grab is being
activated, this may make a difference in the handling of crossing events
triggered through it, e.g. by having callers rely on having already obtained
a ClutterGrab prior to handling the resulting effects.
The "input only" grab has also been turned inactive by default, in order to
to have the ClutterGrab pointer available for checks at the MetaWaylandEventHandler
focus changing methods triggered through grab activation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3463
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3747>
If the titlebar of a window has been moved above the screen by a user
via an unconstrained move, then any constrained user resize following
this move will cause the window to jump below the top of the screen or
cause other glitchy behavior.
This commit removes the constraint that the titlebar of a window must be
below the top of the screen for any resize that is both (1) triggered by
a user and (2) is a resize that affects only the left, right, or bottom
edges of the window. This allows users to move a window partially above
the screen and then resize the window to be wider or resize the bottom
edge of the window to make it taller or shorter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1206
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3764>
This unbreaks building here. The compilation error was due to
MetaX11Display having an incorrect typedef in a now preprocessed out
part, which will be fixed in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3851>
Allows gnome-shell or other compositors to detect which features
were built when building libmutter automatically without having to
expose various build options themselves
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3776>
Moving a window is a compositor action and happens immediately. Waiting
here is pointless. Make sure instead that the action happens immediately
by asserting the position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3842>
wait and wait_configure after a single resize is useless and a race.
Resize is a client side action which doesn't result in a configure and a
wait doesn't sync for a resize as well.
Sometimes the resize is paired with another action, such as maximize,
fullscreen or show. In those cases a configure will be generated and a
previous resize is accounted for.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3842>
Commit e775052429 changed the code such that resetting the actor is done
when a surface role is assigned. The dnd surface assigned vfunc doesn't
chain up which means the code to reset the actor is never hit and the
dnd surface never shows up.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3540
Fixes: e775052429 ("wayland/actor-surface: Reset the actor on role-assignment")
