When we receive a hotplug signal emission, we update the state of leased
and leasable resources. Some of this state depends on the current state
of any potential associated monitor (MetaOutput & MetaMonitor). In order
to have an up to date association of MetaOutput's and MetaMonitor's, we
must only update our own state after MetaMonitorManager has had a chance
to. To achieve this, make sure the MetaUdev::hotplug signal handler is
dispatched after MetaMonitorManager's handler by using
g_signal_connect_after().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3943
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4378>
The original strategy to let the drag source client be in
charge of pointer cursor feedback during DnD has gotten
way too complex, with tablets and tools, toplevel drags,
and now the cursor shape protocol.
Instead, let the compositor be in charge of pointer cursor
feedback during DnD operation, it will know right away the
cursor renderer to update, and the appropriate feedback
through the current DnD action.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4368>
Specifically, only after checking crtc_state_impl->cursor_invalidated.
If that's false, we bail anyway, so no point getting the current cursor
position, which can get blocked by another thread holding the
seat_impl->state_lock in writer mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4377>
When the legacy KMS implementation running without a KMS thread receives
a cursor only frame, it doesn't do an actual page flip, but just posts a
"ready" callback without any timing information. In this case we failed
to discard the posted frame, meaning theh onscreen KMS throttling was
still thinking it was supposed to wait for the posted frame to be
presented.
Fixes: df7ac5b0a3 ("onscreen/native: Account for all posted frames")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/4021
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4375>
What it does now is handling the promotion of a "posted" frame to
"presented", or promoting it to the trash bin, if it was not carrying an
actual primary plane buffer. Promoting to presented effectively still
means "swapping the frm fb" though. Make the name reflect this.
Fixes: df7ac5b0a3 ("onscreen/native: Account for all posted frames")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4375>
meta_wayland_tablet_tool_update_cursor_surface was always creating a new
sprite for the cursor shape, which may result in allocating HW buffers
and uploading the shape to them.
Since meta_wayland_tablet_tool_update_cursor_surface gets called every
time the tablet tool moves, we don't want to repeat that work if the
cursor shape hasn't changed. We cache the sprite in the
MetaWaylandTabletTool struct for reuse next time, and clear the cached
sprite when the cursor shape changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4371>
meta_wayland_pointer_update_cursor_surface was always creating a new
sprite for the cursor shape, which eventually results in allocating HW
buffers and uploading the shape to them.
Since meta_wayland_pointer_update_cursor_surface gets called every time
the pointer moves, we don't want to repeat that work if the cursor shape
hasn't changed. We cache the sprite in the MetaWaylandPointer struct for
reuse next time, and clear the cached sprite when the cursor shape
changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3993
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3996
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4371>
The cache lives on the MetaCursorTracker and thus is shared between all
CursorSpriteXcursors and avoids constantly having to hit the disk when
the cursor shape changes.
We still do a lot of work to get the sprite from the theme into a KMS
plane or drawn into the onscreen, but avoiding disk IO is a first, good
step.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4359>
This happens during shutdown if the cursor is over some clients.
It seems `kms` has lost its cursor manager because the
`prepare-shutdown` signal is emitted to the backend before clients
are closed. While we could just reverse that and close the clients
first, it's not strictly just a "clients" problem. So keeping
the existing shutdown order and just handling when it is NULL seems
like a more universal solution.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2993
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4370>
First instantiate the object, and set the instance pointer in
MetaSeatNative, then initialize it. This is needed due to initializing
libinput may create virtual input devices used for accessibility
features, such as mouse keys, and for this it needs to fetch the
MetaSeatImpl from MetaSeatNative.
Fixes: 5fc60eac ("seat-impl: Keep track of virtual input devices too")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3708
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4374>
The state should go from 'dispatched-one-and-scheduled-later' to
'scheduled-later', not 'scheduled-now' when being notified about a frame
being ready - otherwise we'll dispatch without proper pacing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4334>
The KMS thread handles updates posted asynchronously, but it expects to
only handle one such frame in flight from the compositor at a time. That
means that the triple buffering state tracking in MetaOncreen, that
keeps track of posted frames and when they become presented, must also
account for posted frames that doesn't contain an actual primary plane
pixel buffer.
This was not the case, causing MetaOnscreenNative to post multiple
frames to the KMS thread, which wasn't handled gracefully in certain
situations.
Before the KMS thread grows real support for it's own queue of separate
updates, make sure we keep the contract to the KMS thread in
MetaOnscreenNative, and only submit at most one KMS update for each CRTC
each cycle, even when there are no actual primary plane changes.
v2: Properly handle frame tracking when when KMS update empty
v3: In the page flip callback, only set the presented frame to frames
that has buffers. This is needed on older kernels which doesn't have
drmModeCloseFB() which would otherwise disable the CRTC when presented
frame with an actual buffer would be replaced with an "empty" frame,
causing the frame with the buffer to be released, with the buffer along
with it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4334>
The set of supported color modes of a monitor might change for the same
monitor, for example by the monitor providing different EDID blobs
depending on configuration done on the monitor itself.
When we have a color mode configured that is not actually supported by
the monitor at the moment, amend the configuration and fall back on the
default color mode.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3911
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4364>
MetaWaylandTabletTool is not a GObject thus we cannot use weak pointers
on them. The good news is that MetaWaylandTabletTool structs are perennial
and we do not need to do that.
Remove this unnecessary weak pointer handling, which can only cause
runtime warnings or crashes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4367>
Technically the impl device simple now also supports HDR, but there are
too many things that can go wrong, such as the colorspace prop getting
set, but not the HDR transfer function. For now, we will say that the
simple device impl does not have usable HDR support.
This gets picked up by the MetaOutputKms and propagtes the state to
everywhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4357>
While we do not intend to support HDR on the simple device impl, being
able to get to the default color mode requires support for those
properties. Otherwise, if the monitor is already in HDR mode when mutter
starts, we would be stuck there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4357>
Changing to a cursor shape would set the cursor surface to NULL, so
trying to disable the cursor by setting the cursor surface to NULL was
detected as no-change. This commit fixes the check by taking into
account if the cursor shape is currently set.
Also adds a ref-test for it.
Fixes: 005b969227 ("wayland: Implement the cursor_shape_v1 protocol")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3997
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4358>
Make the prepare function a vfunc of MetaCursorSprite, moving the root
cursor prepare function into MetaCursorSpriteXcursor. This should solve
two issues:
- The root cursor prepare function was changed in f77d8e2a12a07ef6abe9
to solve an issue with fractional scales. The tool cursor prepare
function was missing this fix.
- The cursors created via the shape protocol had no prepare function at
all, so were not getting scaled.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3975
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4345>
In `should_constraint_be_enabled()` calling
`meta_wayland_surface_get_window()` could return a null window when the
toplevel is reset after locking pointer.
The null check was only done inside `HAVE_XWAYLAND` ifdef, and so if
mutter is built without xwayland it could lead to a crash.
Fixes: 6e818c8c38 ("build: Allow disabling xwayland")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4351>
The test is huge and on a very fast machine it takes 10 seconds. So in
Debian and Ubuntu builds we're finding a lot of machines/architectures
where it regularly requires more than a minute to complete.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4340>
Not only if the deadline timer is enabled. With the next commit, it'll
be semi-expected to happen even if the deadline timer is disabled.
Still leave the warning though, as a reminder that we'd rather prevent
this outside of the KMS thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4338>
