[PATCH v4 6/6] drm/doc: Define KMS atomic state set

André Almeida andrealmeid at igalia.com
Sat Jul 1 02:09:17 UTC 2023

Specify how the atomic state is maintained between userspace and
kernel, plus the special case for async flips.

Signed-off-by: André Almeida <andrealmeid at igalia.com>
v4: new patch
 Documentation/gpu/drm-uapi.rst | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 65fb3036a580..5464376051cc 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -486,3 +486,22 @@ and the CRTC index is its position in this array.
 .. kernel-doc:: include/uapi/drm/drm_mode.h
+KMS atomic state
+If a userspace using the DRM atomic API would like to change the modeset, it
+needs to do in an atomic way, changing all desired properties in a single
+commit. Following commits may contain the same properties again, as if they were
+new. The kernel can then judge if those properties requires modesetting and real
+changes, or it's just the same state as before. In summary, userspace commits do
+not need to set the minimal state as possible and can commit redundant
+information, and the kernel will ignore it.
+An observation must be made for atomic operations with DRM_MODE_PAGE_FLIP_ASYNC.
+In such scenarios properties values can be sent, but the if they change
+something, the kernel will reject the flip. This is done because property
+changes can lead to modesetting, that would defeat the goal of flipping as fast
+as possible. The only exceptions are the framebuffer ID to be flipped to and
+mode IDs changes, which could be referring to an identical mode, thus not
+requiring modeset.

More information about the wayland-devel mailing list