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>
This test checks a particular issue, where a pointer moved in a way
resulting in the cursor position not changing, then moving again,
changing the cursor position, not damaging the area of the original
position, causing the cursor to get "stuck" until damaged due to some
other reason.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4331>
The previously painted rectangle of an overlay is not a global state,
but depends on what view it was painted on. There was also an issue
where an overlay being updated but not changing position, e.g. due to a
0,0 pointer movement or an absolute pointer movement with the position
not changing, not properly triggering damage of the old position when it
eventually actually moved.
Fix this by tracking damage per view, while also fixing the state
tracking to handle unchanged positions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4331>
The thing before pretended to be a map but wasn't, so it required
iterating over it and checking the fields to find the requested one. The
code didn't do that and index into it anyway and because the shapes
start at a value of 1, everything was off.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4307>
The protocol changes for version 2 made it upstream but are not in a
release, yet. As soon as we have a release, we should replace this copy
with the wayland-protocols variant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4307>
We run some ref-tests in the tty and kms test harnesses which does
support cursor planes. If we get "unlucky", the cursor could end up on
one of them and won't show up in the captured output.
Inhibit the hardware cursor when capturing the output for a ref-test.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4307>
To not depend on the system cursor theme for tests, always use
our own, even if the cursor theme appearance makes no difference.
We also need to add all of Adwaita's cursors in tree, to avoid any test
arbitrarily triggering missing cursor warnings or errors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4307>
We will start using only the cursors we ship with the tests, which is a
snapshot of Adwaita cursors. left_ptr is not one of the supported ones,
so we use default instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4307>
Cogl and Clutter use the "current source dir" whereas the tests in
src/tests use the non-test source directory. The installed tests already
only use a single directory.
This commit changes everything to be src/test in the source and build
directory.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4307>
KMS can support only very specific cursor sizes and having a cursor that
doesn't match that size isn't something going wrong. Instead of
generating a warning, just log it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4307>
By setting cursor_stage_view->is_hw_cursor_valid and has_hw_cursor and
then skipping to the code below, we can reuse all the logic for when we
need to inhibit/uninhibit and update the sprite.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4307>
As in the commit mentioned below, we dropped the only place where
current_gl_draw_buffer is set. Which was still being used for glx and
ended up causing black screen with multi-monitors & nvidia.
Fixes: aa0600bf2 ("cogl: Remove Framebuffer:stereo-mode")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4323>
