drm/doc: document the type plane property

Add a new entry for "type" in the section for standard plane properties.

v3: improve paragraph about mixing legacy IOCTLs with explicit usage,
note that a driver may support cursors without cursor planes (Daniel)

v4: fixing rebase gone wrong

v5:
- Fix typo (Daniel)
- Mention CAP_ATOMIC instead of CAP_UNIVERSAL_PLANES when referring to
  atomic test-only commits (Daniel)
- Add newlines at end of sections (Daniel)

Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115110626.12233-2-contact@emersion.fr
This commit is contained in:
Simon Ser 2021-01-15 12:06:26 +01:00
parent 7e5d1e122d
commit 97ecfff41e
1 changed files with 54 additions and 4 deletions

View File

@ -50,10 +50,8 @@
* &struct drm_plane (possibly as part of a larger structure) and registers it
* with a call to drm_universal_plane_init().
*
* The type of a plane is exposed in the immutable "type" enumeration property,
* which has one of the following values: "Overlay", "Primary", "Cursor" (see
* enum drm_plane_type). A plane can be compatible with multiple CRTCs, see
* &drm_plane.possible_crtcs.
* Each plane has a type, see enum drm_plane_type. A plane can be compatible
* with multiple CRTCs, see &drm_plane.possible_crtcs.
*
* Each CRTC must have a unique primary plane userspace can attach to enable
* the CRTC. In other words, userspace must be able to attach a different
@ -73,6 +71,58 @@
*
* DRM planes have a few standardized properties:
*
* type:
* Immutable property describing the type of the plane.
*
* For user-space which has enabled the &DRM_CLIENT_CAP_ATOMIC capability,
* the plane type is just a hint and is mostly superseded by atomic
* test-only commits. The type hint can still be used to come up more
* easily with a plane configuration accepted by the driver.
*
* The value of this property can be one of the following:
*
* "Primary":
* To light up a CRTC, attaching a primary plane is the most likely to
* work if it covers the whole CRTC and doesn't have scaling or
* cropping set up.
*
* Drivers may support more features for the primary plane, user-space
* can find out with test-only atomic commits.
*
* Some primary planes are implicitly used by the kernel in the legacy
* IOCTLs &DRM_IOCTL_MODE_SETCRTC and &DRM_IOCTL_MODE_PAGE_FLIP.
* Therefore user-space must not mix explicit usage of any primary
* plane (e.g. through an atomic commit) with these legacy IOCTLs.
*
* "Cursor":
* To enable this plane, using a framebuffer configured without scaling
* or cropping and with the following properties is the most likely to
* work:
*
* - If the driver provides the capabilities &DRM_CAP_CURSOR_WIDTH and
* &DRM_CAP_CURSOR_HEIGHT, create the framebuffer with this size.
* Otherwise, create a framebuffer with the size 64x64.
* - If the driver doesn't support modifiers, create a framebuffer with
* a linear layout. Otherwise, use the IN_FORMATS plane property.
*
* Drivers may support more features for the cursor plane, user-space
* can find out with test-only atomic commits.
*
* Some cursor planes are implicitly used by the kernel in the legacy
* IOCTLs &DRM_IOCTL_MODE_CURSOR and &DRM_IOCTL_MODE_CURSOR2.
* Therefore user-space must not mix explicit usage of any cursor
* plane (e.g. through an atomic commit) with these legacy IOCTLs.
*
* Some drivers may support cursors even if no cursor plane is exposed.
* In this case, the legacy cursor IOCTLs can be used to configure the
* cursor.
*
* "Overlay":
* Neither primary nor cursor.
*
* Overlay planes are the only planes exposed when the
* &DRM_CLIENT_CAP_UNIVERSAL_PLANES capability is disabled.
*
* IN_FORMATS:
* Blob property which contains the set of buffer format and modifier
* pairs supported by this plane. The blob is a struct