Commit Graph

5 Commits

Author SHA1 Message Date
Jonas Ådahl
1cc249fe18 kms: Always predict state after processing update
Not only mode sets have state that should be predicted; changing gamma
currently happens with its own update, so we missed predicting that.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/840
2019-10-10 14:46:32 +00:00
Jonas Ådahl
3e41568074 kms/update: Add helper to get primary plane assignment
Replaces a private static function, with no functional changes made to
it.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/826
2019-10-07 14:59:18 +00:00
Jonas Ådahl
68f18f1fe9 monitor-manager/kms: Use KMS abstraction to get and set CRTC gamma
Still doesn't synchronize with frame drawing, but no point in doing that
until gamma is managed by mutter itself and not gnome-settings-daemon.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/634
2019-06-24 13:36:10 +00:00
Jonas Ådahl
57dfe4696d kms-update: Seal updates when posting them
This makes sure that we won't accidentally change KMS transaction
updates after they have been posted.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:56 +00:00
Jonas Ådahl
75dff3e7c9 backend/native: Add and use transactional KMS API
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/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:56 +00:00