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>
This aims to provide the color state used for compositing for a specific
view. It's currently hard coded to default, but will eventually be
configured depending on the monitor and configuration. It's intended to
be used as a target color state for rendering with color awareness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
The cogl shader cache uses snippet pointers as cache keys, meaning even
if we generate two identical snippets; if they have different pointer
addresses, they'll generate separate cache entries. Handle this by
caching our snippets on the context.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
This helper generates shader snippets that converts pixels from one
color state to another. For example if there is content with sRGB color
state that should be converted to linear BT.2020 before being written to
the framebuffer, a shader that makes the pixel go through the following
steps will be generated:
1. sRGB EOTF
2. Luminance gain (hard coded for now)
3. Color space mapping
The intention is that it should be possible to composite in a linear
color space, into an intermediate framebuffer, which is then passed
through an inverse EOTF to produce linear content in the output color
state.
When transforming from BT.2020/PQ to sRGB/sRGB, clamping to the sRGB
max luminance is done.
Cases where direct transform is also handled, i.e. where one doesn't go
via an linear intermediate buffer, in which case there might be both an
EOTF and an inverted EOTF in the same shader snippet to still do color
space mapping using optical color encoding. This will be used for e.g.
transforming cursor sprites.
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>
The context can be set via a property (currently unused) or via the
current global singleton as a fallback. It means API that acts on an
actor can avoid going via any globals.
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 a3082b8eb3.
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 fec38819ac $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: 0ca933baec ("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>
