Suspending might have changed the CRTC configuration, turning some off,
some on, etc. We need to update our internal representation of this
state, so that we know how to reconfigure upon resuming, e.g. what CRTCs
to turn off again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
When we e.g. try to post an direct client buffer scanout update, it
might arbitrarily fail; when this happen we still will want to post the
rest of the update when we try again after having composited the primary
plane. To do this, add a way to preserve the metadata of an update if it
failed, only dropping the failed plane assignments. This involves
unlocking a previously locked MetaKmsUpdate, so that e.g. a new primary
plane can be assigned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of a "post all pending updates", pass an update specific to a
single device. This gets rid of the awkward "combine feedback" function,
and makes it possible to queue updates to a multiple devices without
always posting them together.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
For now feedbacks from an update are combined, meaning we might lose
error information. The feedback API may have to be reconsidered and
redesigned when planes gets a more front seat position.
This means we need to avoid trying to post updates if we're in power
save mode, as it may be empty.
Note that this is an intermediate state during refactoring that aims to
introduce atomic mode setting support, and we'll stop combining
feedbacks completely in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
The current API as all synchronous, so they can be made to return
feedback immediately. This will be needed for the cursor renderer which
needs to know whether it should fall back to OpenGL cursor rendering.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
This commit introduces, and makes use of, a transactional API used for
setting up KMS state, later to be applied, potentially atomically. From
an API point of view, so is always the case, but in the current
implementation, it still uses legacy drmMode* API to apply the state
non-atomically.
The API consists of various buliding blocks:
* MetaKmsUpdate - a set of configuration changes, the higher level
handle for handing over configuration to the impl backend. It's used to
set mode, assign framebuffers to planes, queue page flips and set
connector properties.
* MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane.
Currently used to map a framebuffer to the primary plane of a CRTC. In
the legacy KMS implementation, the plane assignment is used to derive
the framebuffer used for mode setting and page flipping.
This also means various high level changes:
State, excluding configuring the cursor plane and creating/destroying
DRM framebuffer handles, are applied in the end of a clutter frame, in
one go. From an API point of view, this is done atomically, but as
mentioned, only the non-atomic implementation exists so far.
From MetaRendererNative's point of view, a page flip now initially
always succeeds; the handling of EBUSY errors are done asynchronously in
the MetaKmsImpl backend (still by retrying at refresh rate, but
postponing flip callbacks instead of manipulating the frame clock).
Handling of falling back to mode setting instead of page flipping is
notified after the fact by a more precise page flip feedback API.
EGLStream based page flipping relies on the impl backend not being
atomic, as the page flipping is done in the EGLStream backend (e.g.
nvidia driver). It uses a 'custom' page flip queueing method, keeping
the EGLStream logic inside meta-renderer-native.c.
Page flip handling is moved to meta-kms-impl-device.c from
meta-gpu-kms.c. It goes via an extra idle callback before reaching
meta-renderer-native.c to make sure callbacks are invoked outside of the
impl context.
While dummy power save page flipping is kept in meta-renderer-native.c, the
EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the
frame clock, actual page flip callbacks are postponed until all EBUSY retries
have either succeeded or failed due to some other error than EBUSY. This
effectively inhibits new frames to be drawn, meaning we won't stall waiting on
the file descriptor for pending page flips.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
The intention with KMS abstraction is to hide away accessing the drm
functions behind an API that allows us to have different kind of KMS
implementations, including legacy non-atomic and atomic. The intention
is also that the code interacting with the drm device should be able to
be run in a different thread than the main thread. This means that we
need to make sure that all drm*() API usage must only occur from within
tasks that eventually can be run in the dedicated thread.
The idea here is that MetaKms provides a outward facing API other places
of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is
an internal implementation that only gets interacted with via "tasks"
posted via the MetaKms object. These tasks will in the future
potentially be run on the dedicated KMS thread. Initially, we don't
create any new threads.
Likewise, MetaKmsDevice is a outward facing representation of a KMS
device, while MetaKmsImplDevice is the corresponding implementation,
which only runs from within the MetaKmsImpl tasks.
This commit only moves opening and closing the device to this new API,
while leaking the fd outside of the impl enclosure, effectively making
the isolation for drm*() calls pointless. This, however, is necessary to
allow gradual porting of drm interaction, and eventually the file
descriptor in MetaGpuKms will be removed. For now, it's harmless, since
everything still run in the main thread.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
