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>
Use an enum and an array to enumerate the keyboard LEDs and
map xkb_led_index_t to libinput_led. There are future additions
coming and this will be extensible without becoming too spaghetti.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4301>
So that if somehow it does return early then we're not left with an
allocated `clutter_frame_clock_new_frame` that is never dispatched
(which then leads to the pool being exhausted a frame or two later).
It's not yet clear how it comes to this where the source is dispatched
and the state unscheduled, but at least the more detailed logging here
will help us to identify which state it came from.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3945
Fixes: 394bf5ab24 ("clutter/frame-clock: Add triple buffering support")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4316>
When a client binds to the a device, if obtaining a non-privileged fd
fails, instead of returning an error, put the client in a pending
queue.
Delaying the drm_fd is allowed by the protocol definition:
The compositor will send this event when the wp_drm_lease_device_v1
global is bound, although there are no guarantees as to how long
this takes [...]
A future commit will send the drm_fd events to the clients in the list
once Mutter can obtain a valid fd.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3921>
This might be possible if extended target volume is supported but
currently it isn't.
This is a requirement from the wayland color management:
"'reference_lum' may be higher than 'max_lum'. In that case reaching
the reference white output level in image content requires the
'extended_target_volume' feature support."
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4304>
This is a requirement from the wayland color management:
"With transfer_function.st2084_pq the given 'max_lum' value is
ignored, and 'max_lum' is taken as 'min_lum' + 10000 cd/m²."
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4304>
