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>
If crtc->current_state.is_drm_mode_valid happens to be FALSE,
meta_kms_crtc_determine_deadline returns G_IO_ERROR_NOT_FOUND. This
previously resulted in silently and permanently disabling the deadline
timer, which is surprising and undesirable.
Bail early from ensure_deadline_timer_armed in this case instead. In
turn, G_IO_ERROR_NOT_FOUND from meta_kms_crtc_determine_deadline no
longer needs to be treated specially.
Fixes: 7493ed39ce20 ("kms/impl-device: Avoid retrying a failing deadline timer")
v2:
* Stop treating G_IO_ERROR_NOT_FOUND specially. (Sebastian Wick)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4321>
If ensure_deadline_timer_armed fails and crtc_frame->pending_update is
non-NULL, we need to process the pending update, or it may fall through
the cracks, and this stage view may freeze.
v2:
* Don't return immediately after calling
meta_kms_impl_device_do_process_update. (Sebastian Wick)
v3:
* Call meta_kms_impl_device_do_process_update only if
is_using_deadline_timer returned true, and log a warning if
crtc_frame->pending_update is non-NULL otherwise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4321>
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: [Michel Dänzer]
* Drop Closes due to
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4334#note_2378962.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4321>
No actual changes. We will use this version to hint GTK about
the availability of non broken wl_surface.offset support for
pointer cursors.
GTK can use this version to avoid cursor breakage when running
on older Mutter versions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4327>
Any feedbacks for the same stage view but older frames than the one
being presented are discarded.
Since we now use per-frame lists of feedbacks, there can no longer be
any stale feedbacks where we previously discarded them, so remove that
dead code.
v2:
* Use ClutterFrameInfo::frame_count.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4306>
