MetaRendererViewNative is a MetaRendererView which contains logic
specific to views of the native backend. It will be used by following
commits.
In the future, per-view logic from MetaRendererNative can be moved to
MetaRendererViewNative where it makes more sense to have it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
Instead of using the "discarded" page flip callback when the
"discarding" happened during actual immediate processing, communicate
the same via the KMS update feedback.
The "discarded" page flip callback is instead used only for when a
posted page flip is discarded. In the atomic backend, this only happens
on shutdown, while in the simple backend, this also happens when a
asynchronous retry sequence eventually is abandoned.
This allows further improvements making KMS handling fully async.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
At first it was called seal(), but then updates could be amended after
being posted, given a flag. That flag has been removed, so we can go
back to sealing, since it's once again acts more as a seal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
We test direct client buffer scanout using a TEST_ONLY commit on atomic,
and with various conditions in non-atomic, but if we end up failing to
actually commit despite this, handle the fallout asynchronously. What
this means is that we'll reschedule a new frame immediately.
For this to work, the same scanout buffer needs to be avoided for the
same CRTC. This is done by using the newly added signal on the
CoglScanout object to let the MetaWaylandBuffer object mark the current
buffer as non-working for the onsrceen that it failed on. This allows to
re-try buffers on the same onscreen when new ones are attached.
This queues a full damage, since we consumed the qeued redraw rect. The
redraw rect wasn't lost - it was accumulated to make sure the whole
primary plane was redrawed according to the damage region, whenever we
would end up no longer doing direct scanout, but this accumulation only
works when we're not intentionally stopping to scanout. For now, lets
just damage the whole view, it's just an graceful fallback in response
to an unexpected error anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
If we get a "ready" page flip feedback, it means the page flip was
symbolic, i.e. not real, e.g. as a result of an update that didn't
change the state of the primary plane. Warn if there is a "next fb"
meaning we expected to have a new buffer that we flipped to.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This is intended to be used only for plane assignment, and CRTC like
changes, so that one can e.g. change a cursor plane on a pending update
that changes the primary plane, before it has been committed to KMS.
The kms-updates test overrides the get-state function MetaKmsCrtc. This
is needd to not have the update mechanism not clamp the gamma size to 0,
as vkms reports the gamma length 0. By pretending it's 3, we can test a
simple and small gamma lut is merged correctly when merging updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
Allows for creating LUTs at some fixed size which maintains enough
precision for concatenating or otherwise manipulating the LUT without
having to care about the precision of the hardware.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
If the device supports the atomic API the property based API is used to
write gamma updates and the legacy API is used in the non-atomic case.
The current state is read from the legacy API always though which can be
different from the property API. This commit always uses the correct API
to update the state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
With detach meaning having the onscreen stop listening on configuration
changes on the corresponding backing mode setting objects. We need to do
this as there is a time between rebuilding the views, and that the new
mode sets are called, where the old onscreen is kept alive, but the
stage view is gone. At this point in time, if privacy screen or gamma
configuration changes, e.g. by the night light temperature changing, the
onscreen would attempt to schedule an update on the now gone stage view.
This commit also renames the "keep onscreen alive" to "detached
onscreens" to more clearly communicate that it's detached onscreens from
their corresponding mode setting objects.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2621
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2863>
For the coordinates of pointers or stylii, we translate the ones we store
using the viewport matrix already. For touch events otoh, we store coords
untranslated and translate them later only for event emission.
Let's be consistent here and store the coordinates of touch events
translated, just like we do for pointer events.
This fixes touch window dragging on rotated monitors. MetaWindowDrag calls
clutter_seat_query_state(), which uses those stored coordinates. So in case
of a touch sequence the coords returned by query_state() would be
untranslated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2859>
Doing it in dispose means the backend is actively tearing down itself,
meaning various components might or might not be there, depending on how
the tearing down is implemented. Make things a bit more robust by doing
any work that might rely on the backend being there before shutdown is
done in response to the 'prepare-shutdown' signal being emitted by the
backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2853>
So we can remove the additional `next_fb` and `current_fb` pointers from
`MetaOnscreenNativeSecondaryGpuState`.
Some non-scanout buffers also need to be held in the case of GL blitting
which completes in the background. Those are referenced from the scanout
buffers themselves to ensure the source buffers live just as long.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2087>
As with GAMMA_LUT, track whether privacy screen state has been pushed to
KMS in the onscreen. This leaves MetaOutput and MetaCrtc to be about
configuration, and not application.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
As with CRTC GAMMA_LUT, we're moving towards making the entity managing
KMS updates aware if there are any changes to be made, and whether KMS
updates are actually needed or not, and for privacy screen changes, this
means we need to communicate whether the privacy screen state is valid
or not. This allows the caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We're moving towards making the entity managing KMS updates aware if
there are any changes to be made, and whether KMS updates are actually
needed or not, and for GAMMA_LUT changes, this means we need to
communicate whether the GAMMA_LUT state is valid or not. This allows the
caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
When the pointer crosses monitors, we account for a single motion event
resulting in the pointer moving across more than 2 monitors, in order
to correctly account each monitor scale and the distance traversed
across each monitor in the resulting relative motion vector.
However, memory on the direction is kept short, each iteration to
find the target view just remembers the direction it came from. This
brings a pathological case with 4 monitors with the same resolution
in a 2x2 grid, and a motion vector that crosses monitors at the
intersection of all 4 in a perfect diagonal. (Say, monitors are
all 1920x1080 and pointer moves from 1920,1080 to 1919,1079).
In that case, the intersection point at the crossing between 4
monitors (say, 1920,1080) will be considered to intersect with 2
edges of each view. Since there is always at least 2 directions to
try, the loop will always find the direction other than the one
it came from, and as a result endlessly jump across all 4 possible
choices.
In order to fix this, consider only the global v/h directions,
we already know if the pointer moves left/right or up/down, so
only consider those directions to jump across monitors.
For the case at hand, this will result in three monitors visited,
(either bottomright/bottomleft/topleft, or bottomright/topright/topleft)
with a total distance of 0,0 in the middle one, effectively
resulting in a correct diagonal motion.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2598
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
Refactor code so that variables don't depend the on motion line
content, but the other way around. This makes it clearer what each
vector means.
This has no functional changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
Commit 4e0ffba5c attempted to fix initialization of keyboard a11y,
but mousekeys do attempt to create a virtual input device at a
time that it is too early to try to create one.
Defer this operation until keyboard devices are added, so that
we are ensured to already have the seat input thread set up.
Fixes: 4e0ffba5c - backends/native: Initialize keyboard a11y on startup
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2778>
