Previously the color device was destroyed when it was attached to a
monitor that was going away. However, the MetaMonitor objects are
ref-counted and can stay around for longer, even if the underlying
resources went away. We need color devices for as long as the
MetaMonitors are alive.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3904>
Every monitor should eventually have a corresponding color device. To
make sure this can work, we must handle situations where the color
manager didn't connect to colord yet, and thus isn't ready.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3904>
When triple buffering, `meta_onscreen_native_prepare_frame` for the next
frame is called before `notify_view_crtc_presented` for the previous frame.
So our booleans were unfortunately still TRUE in the second prepare_frame,
resulting in two frames with the same property updates.
When double buffering, having roughly one frame interval between
`meta_onscreen_native_prepare_frame` and `notify_view_crtc_presented`
meant that property updates signalled between the swap and presentation
wouldn't get attached to a KMS update, and would be forgotten when
`notify_view_crtc_presented` resets the flags to FALSE.
To solve these we now keep a separate flag and counter per property,
tracking invalidation and pending updates respectively. The latter is a
counter rather than a boolean in support of triple buffering where two
updates may be pending concurrently (next and posted).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3912>
Add a new service client type for a filechooser portal client, and
expose the x11_interop protocol to it.
This will be used to make Nautilus a file chooser portal implementation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3694>
Because if the current theme has exceeded the dimensions of
`DRM_CAP_CURSOR_WIDTH/HEIGHT` then the warning is just going to repeat
every time the cursor changes. We still fall back to software cursors
just fine so it's not important to repeat the warning.
In Mutter 46 the warning was "Invalid theme cursor size". Same problem.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3597
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3924>
As it was originally the function to be used before
making it private and providing safer wrappers around it for x11/win32.
Nowadays, it is only used in x11 and only internally in mutter, exposing
a 'safer' variant costs us exposing more of x11 renderer APIs without
much benefits.
With this change, the only internal xlib renderer we need from meta is
set_foreign_display which can't be easily worked around
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3910>
material is almost no longer used in the code base and the
few remaining references makes it confusing when looking at parts
of the codebase. So rename the rest as well.
Note that this renames a DeformEffect property and the only extension
making use of it doesn't use the property so i think it is okay to do
so without deprecating the old property for a few releases
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3910>
The OpenGL specs say rounding is preferred, but not required. Let's
avoid that uncertainty by choosing a test value that rounds and truncates
to the same integer either way. Only green needs fixing since our red,
blue and alpha values already follow this rule.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3903>
Simply to make it clear that the renamed function is specific to a
particular X11 initialization mode (mandatory Xwayland), put that in the
name, so that it's easier to understand when this function is relevant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329>
This means that for X11 sessions we'll do it before any windows are
mapped, and before any plugin implementation is started. Doing it before
a plugin is started is important, because things that the plugin does
during startup can have consequences on how compositing on Xorg works.
For the Xwayland case, we'll do it relatively in the setup phase. It
appears to have been harmless to do it later in the post-opened signal,
but there is no harm in doing it as one of the earlier steps.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3089
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329>
by executing `global.context.get_debug_control().exported = true`.
This makes it possible to get access to the debug service without having
to start with `--enable-debug`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3902>
This means the pipeline can be manipulated after retrieving. This also
fixes a leak when adding pipelines to the cache, as we the pipeline
would take a ref, but when adding, we wouldn't clean up our own ref.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3897>
The drm subsystem has been moving over to gitlab for some time now and
the old anongit.freedesktop.org remote is becoming unusable. Contains
the same repo with the same tags, so this shouldn't result in any
differences.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3896>
Having an always-on-top window affects focus granting logic if the
to be showing window overlaps with any of them. Instead of triggering
the focus denying logic if a new window ever so slightly touches an
always-on-top window to only triggering if it's covered more than 60% by
always-on-top windows.
This is intended to make using always-on-top windows a bit less annoying
and not cause as many unintended focus-on-map denials.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
When we show a window, we'll check if it overlaps with an existing
always-on-top window with the intention to deny focus. However, we did
this potentially before having placed the window, meaning we effectively
checked as if it was placed at (0, 0), which created unexpected results.
Instead check the overlap state after placing. A window placement test
case is added to verify this works as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
Replace a boolean argument and a temporary MetaWindow struct field with
a `MetaPlaceFlag` passed where relevant. This includes
`meta_window_move_resize_internal()` and `meta_window_constrain()`, as
placement may happen during constraining, and also
`meta_window_force_placement()`.
The struct field (denied_focus_and_not_transient) was only ever set in
meta_window_show(), before meta_window_force_placement(), and
immediately unset as a side effect of that. In .._show() we'll always
force placement if the window wasn't already placed, and in
meta_window_constrain(), we'd only ever call meta_window_place() if the
window wasn't already placed, meaning the variable would only ever be
relevant during `meta_window_show()`. Having it as a flag makes that
relationship and temporary state clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
The function checking whether a 'always-on-top' window covers the
showing window now has that in the name, to make it more obvious. That
function was also changed to use the more common way of iterating a
list, and now uses auto cleanup pointers for the list.
The condition itself was updated to follow the current coding style.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
It won't be used until later when we flip, and in fact assigning
it early could have led to its own assertion failing on the next frame
in the unlikely event that we return with "Failed to ensure KMS FB ID...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3891>
This avoids the following critical warning happening sometimes when a
Wayland client exits taking all its window with it in an arbitrary
order:
CRITICAL: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
This, in contrast to 'assert_stacking' only checks showing windows. This
is useful when doing workspace tests, where one want to check what
windows are currently visible.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
When a transient window becomes transient, check if the parent is
sticky, and if it is, make the transient sticky as well. This handles
situations where e.g. a utility dialog (such as search and replace) is
opened on a sticky window, also making the utility dialog sharing the
same stickyness state.
This is also more in line with the semantics of making a window sticky,
where transient would implicitly become sticky as a side effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
If a transient window is sticky (visible on all workspaces) and it gets
activated, we'd call move_worskpace() which would effectively unstick
it, which is rather unexpected. It'd also effectively unstick its parent
as well, due to moving a transient window also moves its descendants and
ascendants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
Introduced in libinput 1.26 this feature allows restricting the
tablet tool pressure range to a subset of its physical range. The
use-case is either to require some higher-than-usual minimum pressure
before the pen reacts, or lower-than-usual pressure to reach the maximum
logical pressure.
libinput takes a [0.0, 1.0] normalized range which we expose as percent
in the gsettings. The wacom driver doesn't have an exact equivalent but
it has a Threshold setting (range [1, 2048]) that defines when a button
is generated for tip down.
See gsettings-desktop-schemas!84
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3794>
This mapper hooks into CLUTTER_BUTTON_PRESS/RELEASE events with a
clutter button of zero but a nonzero evcode (e.g. BTN_STYLUS).
It then looks up the available button actions and implements
switch-monitor and keybindings using the MetaTabletActionMapper parent
class.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Unlike most other schemas the path for a tool requires a bit of
processing (serial number or tablet vid/pid if there's no serial number).
Let's make the tool settings available through the MetaInputSettings
instead of having to duplicate that path composition in the caller.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Stylus actions that don't map into LMR or back/forward are now created
as a clutter button event with a button number of zero. Nothing is
actually done with those events for now, they're just discarded later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
For stylus buttons we apply a button mapping, e.g. secondary button ->
right. This mapping was previously applied to the clutter event's evdev
code only, not the actual clutter button. As a result, gnome-shell would
always treat the BTN_STYLUS as middle and BTN_STYLUS2 as right,
regardless of the mapping.
Move the mapping up so we first adjust our evcode, then proceed with
the usual mappings.
Note that this temporary breaks the stylus mapping to Back/Forward which
will be fixed in a follow-up commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Use the helper function for mapping a stylus tool evdev code to a
clutter button code. This fixes a (theoretical) issue - if a tool were
to send any button other than the one we handled those would likely be
BTN_SIDE and friends and we'd likely end up with negative button
numbers. The BTN_TOOL_PEN range is not predicable enough to do any sort
of calculation conversion because things like BTN_TOOL_DOUBLETAP have
specific meanings that aren't actually buttons.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
This complements the existing clutter->evdev and evdev->clutter helpers,
but this time for buttons we expect from a stylus tool. We also need to
convert left/middle/right for the Wacom puck/lens cursor tools but that
particular conversion is lossy.
Note that these are more restrictive than the normal codes - if we
get "other" buttons from a stylus we don't really know what they could
possibly map to. So we safely map what looks like buttons from a mouse
but otherwise complain and return zero.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
This is prep work for using the same functionality for tablet tools as
well. The new MetaTabletActionMapper takes care of the event bubbling
via the device-added/removed and input-event signals and provides the
helper functions to cycle outputs and/or emulate keybindings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Instead of using cairo for scaling and rotating cursors before putting
them on a plane, use Cogl. For now still download them back to the CPU
so we can place them on a dumb buffer, but can explore rendering to a
DMA buffer directly as a future improvement.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
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 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>
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")
In these checks, it's an important detail to preserve subpixel information
in order to correctly determine whether the coordinates are inside or
outside a view.
Otherwise, small enough motion towards the left/top might get rounded
to 0, be seen as "inside the view", and the pointer coordinates be allowed
to escape the viewport constraints.
This was figured out by Pascal Nowack before me, with a difference of
minutes. Credit where credit is due.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3530
Fixes: 6c972546f1 ("mtk: Add Rectangle.contains_point")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3820>
In meta_seat_impl_remove_virtual_input_device(), the 'device'
variable is first removed from MetaSeatImpl, then a "device
removed" event is generated with it.
The problem here is that, if this is the last reference of
'device', the removal from MetaSeatImpl will destroy it. Then
the freed variable will be used to create the "device removed"
event, which is a use-after-free situation.
Fix that by owning an extra ref to 'device' as long as the
function is executing. Do this by declaring a g_autoptr
variable with the extra ref. This g_autoptr variable is cleaned
up by the end of the function, which achieves the desired effect.
Spotted by Coverity.
CID: #1594046
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3835>
Right now the unmapped signal doesn't always fire which means we didn't
see a surface that's being unmapped in these code paths before. In
particular the resource, window and role can be gone. Handle those
cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3783>
