mutter:wip/gbsneto/kms-transactions-on-steroids

Last commit made on 2019-06-19
Get this branch:
git clone -b wip/gbsneto/kms-transactions-on-steroids https://git.launchpad.net/mutter

Branch merges

Branch information

Name:
wip/gbsneto/kms-transactions-on-steroids
Repository:
lp:mutter

Recent commits

cf9136e... by Georges Basile Stavracas Neto

backend/native: Port gamma management to Atomic KMS API

As a side note: fun things happen when gamma is set wrong!

6f43602... by Georges Basile Stavracas Neto

native-renderer: Remove unused variables

d147cc3... by Jonas Ådahl

backends/native: Add some KMS debug logging

Using the g_debug() macro. Set G_DEBUG_MESSAGES to "mutter" to activate
log.

https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525

f980445... by Jonas Ådahl

kms: Add high level code documentation

Document the high level components of the KMS abstraction.

https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525

5977c1a... by Jonas Ådahl

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

ff6ef0e... by Jonas Ådahl

logical-monitor: Pass output when iterating over CRTCs

While not currently used by any users, it'll be useful in future
commits.

https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525

9583632... by Jonas Ådahl

backend/native: Move some KMS utilities to its own file

They are not strictly related to any of the KMS objects, and should be
reusable without adding a dependency on the non-meta-kms-* files in
meta-kms-*.

https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525

0a1ea14... by Jonas Ådahl

kms: Add API to register impl file descriptors

To let the MetaKmsImpl implementation register file descriptor GSource
where the invoke function is ensured to be executed in the impl context.

https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525

8ba01d3... by Jonas Ådahl

kms: Add API to add a GSource that'll be invoked in the impl context

The MetaKmsImpl implementation may need to add a GSource that should be
invoked in the right context; e.g. a idle callback, timeout etc. It
cannot just add it itself, since it's the responsibility of MetaKms to
determine what is the impl context and what is the main context, so add
API to MetaKms to ensure the callback is invoked correctly.

It's the responsibility of the caller to eventually remove and destroy
the GSource.

https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525

a47d42f... by Jonas Ådahl

kms: Add API to post callbacks out of the impl context

While the current impl context is in the same thread as the main
context, the separation still exists, and to post callbacks from the
impl context, it must pass MetaKms to make sure the callback is invoked
in the right context.

https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525