On Mon, Sep 23, 2019 at 12:39:20PM +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 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.
Some Arm's usage cases about two planes with same zpos.
- "Smart layer"
which can accepts 4 different fbs with different src/display rect,
but this smart layer has one restriction:
4 display rects must have no overlaps in V direction
(A optimization for android window like Toolbar/Navigation bar)
So when map this Smart-layer to drm world, it might be 4 different
drm-planes, but with same zorder to indicate that these 4 planes are
smart-laye planes.
- "VR-Layer"
One VR-layer comprises two different viewports which can be configured
with totoally different fbs, src/display rect.
we use two differernt drm-planes to drive on HW "VR-Layer", and these
two drm-planes must be configured with same zpos.
Thanks
James
> 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)
>
> 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)
>
> Signed-off-by: Simon Ser <contact@xxxxxxxxxxx>
> Cc: Pekka Paalanen <ppaalanen@xxxxxxxxx>
> Cc: Marius Vlad <marius.vlad@xxxxxxxxxxxxx>
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
> ---
> drivers/gpu/drm/drm_blend.c | 8 ++++----
> include/drm/drm_plane.h | 9 +++++----
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> --
> 2.23.0
>
> 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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
