[PATCH v2 5/9] drm/doc: document the type plane property

[Daniel Vetter]

On Thu, Dec 17, 2020 at 12:32:16PM +0100, Simon Ser wrote:
> Add a new entry for "type" in the section for standard plane properties.
> 
> Signed-off-by: Simon Ser <contact at emersion.fr>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Pekka Paalanen <ppaalanen at gmail.com>
> ---
>  drivers/gpu/drm/drm_plane.c | 52 ++++++++++++++++++++++++++++++++++---
>  1 file changed, 48 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 4a66374dc355..fef63bb7d293 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -49,10 +49,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.
>   *
>   * Legacy uAPI doesn't expose the primary and cursor planes directly. DRM core
>   * relies on the driver to set the primary and optionally the cursor plane used
> @@ -66,6 +64,52 @@
>   *
>   * 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_UNIVERSAL_PLANES
> + *     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. Note that
> + *     &DRM_CLIENT_CAP_UNIVERSAL_PLANES is implicitly enabled by
> + *     &DRM_CLIENT_CAP_ATOMIC.
> + *
> + *     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.
> + *
> + *         User-space must not mix the legacy IOCTLs &DRM_IOCTL_MODE_SETCRTC or
> + *         &DRM_IOCTL_MODE_PAGE_FLIP with atomic commits involving a primary
	s/a primary/any primary/

to make it a bit stronger

> + *         plane.

You can also use primary planes through the setplane ioctl. Also this
doesn't explain why, which is maybe a bit head scratching.

I'd put something like "Primary planes are used implicitly by the kernel
in the legacy IOCTLs SETCRTC & FLIP. Therefore userspace must not mix
explicit usage of any primary plane (e.g. through ATOMIC IOCTL) with these
legacy IOCTL." Feel free to bikeshed further.

> + *     "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.
> + *
> + *         User-space must not mix the legacy IOCTLs &DRM_IOCTL_MODE_CURSOR or
> + *         &DRM_IOCTL_MODE_CURSOR2 with atomic commits involving a cursor
> + *         plane.

Same here.

Maybe we should also note that cursors are not necessarily exposed as
cursor planes, even for drivers supporting atomic modeset.
-Daniel

> + *     "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
> -- 
> 2.29.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch