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>
Ensure the window is placed in coordinates, before maximizing, tiling or
minimizing it. This should make the window maximized/tiled on the right
(or correctmost) monitor given the stored coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4311>
Ensure that windows get restored either in maximized and unmaximized
state. And ensure that monitors being removed result in windows
snapping back to reachable positions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4311>
We don't want triple buffering when the estimated maximum update time is
known and no larger than a refresh interval. In that case, regular frame
clock dispatch is scheduled after the previous frame is presented, so no
third buffer is necessary.
Allowing triple buffering anyway was problematic when frames are skipped
for reasons other than the frame update taking too long (e.g.
https://gitlab.gnome.org/GNOME/mutter/-/issues/3884):
1. First frame dispatches, targets display refresh cycle (DRC) n, but
skips
2. Second frame dispatches, targets DRC n+1
3. First frame is presented at DRC n+1
4. Second frame is presented at DRC n+2
Without triple buffering:
2. First frame is presented at DRC n+1
3. Second frame dispatches, targets DRC n+2
4. Second frame is presented at DRC n+2
The second frame is presented at DRC n+2 in both cases, but with triple
buffering it targeted n+1, i.e. its contents might not be consistent
with when it's presented.
It gets worse with triple buffering if the second frame also skips:
4. Second frame skips, is presented at DRC n+3
That's a discrepancy of 2 refresh cycles between the target and
effective presentation time, which might be noticeable as more severe
stutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4282>
