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

Submitted by Simon Ser on Oct. 9, 2019, 3:10 p.m.

Details

Message ID T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr
State New
Headers show
Series "drm: two planes with the same zpos have undefined ordering" ( rev: 6 ) in DRI devel

Not browsing as part of any series.

Commit Message

Simon Ser Oct. 9, 2019, 3:10 p.m.
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 unspoken, legacy rule used in the past was to make user-space figure
out the zpos from object IDs. However some drivers break this rule,
that's why the ordering is documented as unspecified in case the zpos
property is missing. User-space should rely on the zpos property only.

There are some cases in which user-space might read identical zpos
values for different planes.

For instance, in case the property is mutable, user-space might set two
planes' zpos to the same value. This is necessary to support user-space
using the legacy DRM API where atomic commits are not possible:
user-space needs to update the planes' zpos one by one.

Because of this, user-space should handle multiple planes with the same
zpos.

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. In other words, when user-space sets
the same zpos on two planes, drivers should rely on the plane object ID.

v2: clarify drm_plane_state.zpos docs (Daniel)

v3: zpos is for all planes (Marius, Daniel)

v4: completely reword the drm_plane_state.zpos docs to make it clear the
recommendation to use plane IDs is for drivers in case user-space uses
duplicate zpos values (Pekka)

v5: reword commit message (Pekka, James)

v6: remove mention of Arm GPUs having planes which can't overlap,
because this isn't uAPI yet (Daniel)

Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Marius Vlad <marius.vlad@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: James Qian Wang <james.qian.wang@arm.com>
---
 drivers/gpu/drm/drm_blend.c | 8 ++++----
 include/drm/drm_plane.h     | 9 +++++----
 2 files changed, 9 insertions(+), 8 deletions(-)

--
2.23.0

Patch hide | download patch | download mbox

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().
  *
  * 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..328773690851 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -140,10 +140,11 @@  struct drm_plane_state {
 	 * @zpos:
 	 * 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.
+	 * User-space may set mutable zpos properties so that multiple active
+	 * planes on the same CRTC have identical zpos values. This is a
+	 * user-space bug, but drivers can solve the conflict by comparing the
+	 * plane object IDs; the plane with a higher ID is stacked on top of a
+	 * plane with a lower ID.
 	 *
 	 * See drm_plane_create_zpos_property() and
 	 * drm_plane_create_zpos_immutable_property() for more details.

Comments

On Wed, Oct 09, 2019 at 03:10:49PM +0000, Simon Ser 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 unspoken, legacy rule used in the past was to make user-space figure
> out the zpos from object IDs. However some drivers break this rule,
> that's why the ordering is documented as unspecified in case the zpos
> property is missing. User-space should rely on the zpos property only.
> 
> There are some cases in which user-space might read identical zpos
> values for different planes.
> 
> For instance, in case the property is mutable, user-space might set two
> planes' zpos to the same value. This is necessary to support user-space
> using the legacy DRM API where atomic commits are not possible:
> user-space needs to update the planes' zpos one by one.
> 
> Because of this, user-space should handle multiple planes with the same
> zpos.
> 
> 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. In other words, when user-space sets
> the same zpos on two planes, drivers should rely on the plane object ID.
> 
> v2: clarify drm_plane_state.zpos docs (Daniel)
> 
> v3: zpos is for all planes (Marius, Daniel)
> 
> v4: completely reword the drm_plane_state.zpos docs to make it clear the
> recommendation to use plane IDs is for drivers in case user-space uses
> duplicate zpos values (Pekka)
> 
> v5: reword commit message (Pekka, James)
> 
> v6: remove mention of Arm GPUs having planes which can't overlap,
> because this isn't uAPI yet (Daniel)
> 
> Signed-off-by: Simon Ser <contact@emersion.fr>
> Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Marius Vlad <marius.vlad@collabora.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: James Qian Wang <james.qian.wang@arm.com>

Applied, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_blend.c | 8 ++++----
>  include/drm/drm_plane.h     | 9 +++++----
>  2 files changed, 9 insertions(+), 8 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().
>   *
>   * 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..328773690851 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -140,10 +140,11 @@ struct drm_plane_state {
>  	 * @zpos:
>  	 * 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.
> +	 * User-space may set mutable zpos properties so that multiple active
> +	 * planes on the same CRTC have identical zpos values. This is a
> +	 * user-space bug, but drivers can solve the conflict by comparing the
> +	 * plane object IDs; the plane with a higher ID is stacked on top of a
> +	 * plane with a lower ID.
>  	 *
>  	 * See drm_plane_create_zpos_property() and
>  	 * drm_plane_create_zpos_immutable_property() for more details.
> --
> 2.23.0
> 
>