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 f77d8e2a12
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: 7493ed39ce ("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>
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>
