Specify how the atomic state is maintained between userspace and
kernel, plus the special case for async flips.
Signed-off-by: André Almeida <andrealmeid@xxxxxxxxxx>
---
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
:internal:
+
+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.
--
2.41.0
