[PATCH v3] drm: two planes with the same zpos have undefined ordering

[Pekka Paalanen]

On Wed, 18 Sep 2019 16:33:47 +0000
Simon Ser <contact at emersion.fr> wrote:

> Currently the property docs don't specify whether it's okay for two planes to
> have the same zpos value and what user-space should expect in this case.
> 
> The rule mentionned in the past was to disambiguate with object IDs. However
> some drivers break this rule (that's why the ordering is documented as
> unspecified in case the zpos property is missing). Additionally it doesn't
> really make sense for a driver to user identical zpos values if it knows their
> relative position: the driver can just pick different values instead.
> 
> So two solutions would make sense: either disallow completely identical zpos
> values for two different planes, either make the ordering unspecified. To allow
> drivers that don't know the relative ordering between two planes to still
> expose the zpos property, choose the latter solution.
> 
> While at it, remove the assumption that zpos is only for overlay planes.
> 
> Additionally, update the drm_plane_state.zpos docs to clarify that zpos
> disambiguation via plane object IDs is a recommendation for drivers, not
> something user-space can rely on.
> 
> v2: clarify drm_plane_state.zpos docs (Daniel)
> 
> v3: zpos is for all planes (Marius, Daniel)
> 
> Signed-off-by: Simon Ser <contact at emersion.fr>
> Cc: Pekka Paalanen <ppaalanen at gmail.com>
> Cc: Marius Vlad <marius.vlad at collabora.com>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
>  drivers/gpu/drm/drm_blend.c | 8 ++++----
>  include/drm/drm_plane.h     | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index d02709dd2d4a..121481f6aa71 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -132,10 +132,10 @@
>   *	planes. Without this property the primary plane is always below the cursor
>   *	plane, and ordering between all other planes is undefined. The positive
>   *	Z axis points towards the user, i.e. planes with lower Z position values
> - *	are underneath planes with higher Z position values. Note that the Z
> - *	position value can also be immutable, to inform userspace about the
> - *	hard-coded stacking of overlay planes, see
> - *	drm_plane_create_zpos_immutable_property().
> + *	are underneath planes with higher Z position values. Two planes with the
> + *	same Z position value have undefined ordering. Note that the Z position
> + *	value can also be immutable, to inform userspace about the hard-coded
> + *	stacking of planes, see drm_plane_create_zpos_immutable_property().

Hi,

the above looks good to me.

>   *
>   * pixel blend mode:
>   *	Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index cd5903ad33f7..7ac68057b19d 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -141,9 +141,9 @@ struct drm_plane_state {
>  	 * Priority of the given plane on crtc (optional).
>  	 *
>  	 * Note that multiple active planes on the same crtc can have an
> -	 * identical zpos value. The rule to solving the conflict is to compare
> -	 * the plane object IDs; the plane with a higher ID must be stacked on
> -	 * top of a plane with a lower ID.
> +	 * identical zpos value. To solve the conflict, the recommendation to
> +	 * drivers to avoid surprises is to compare the plane object IDs; the
> +	 * plane with a higher ID is stacked on top of a plane with a lower ID.

While better, I think this would need a less subtle clarification:

+ "Userspace should never rely on stacking order derived from IDs."

Oh, I think I realised it only now. This comment is for the drivers to
handle a case where userspace is being stupid and assigns mutable zpos
properties with duplicate values, right?

It does *not* allow drivers themselves to assign duplicate zpos values.
So I've been looking at this from the wrong angle.

Maybe it should just say that then?

Instead of:

	"Note that multiple active planes on the same crtc can have an
	identical zpos value. The rule to solving the conflict is to
	compare the plane object IDs;"

The paragraph could start with:

	"Userspace may set mutable zpos properties so that multiple
	active planes on the same crtc have identical zpos value. This
	is a userspace bug, but drivers can solve the conflict
	deterministically by comparing the plane object IDs;"


Thanks,
pq

>  	 *
>  	 * See drm_plane_create_zpos_property() and
>  	 * drm_plane_create_zpos_immutable_property() for more details.
> --
> 2.23.0
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190919/28fad12b/attachment.sig>