On Wed, Sep 18, 2019 at 1:14 PM Marius Vlad <marius.v...@collabora.com> wrote:
>
>
>
> On 9/17/19 8:24 PM, 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.
> >
> > 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)
> >
> > Signed-off-by: Simon Ser <cont...@emersion.fr>
> > Cc: Pekka Paalanen <ppaala...@gmail.com>
> > Cc: Marius Vlad <marius.v...@collabora.com>
> > Cc: Daniel Vetter <daniel.vet...@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..51bd5454e50a 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 overlay planes, see
> > drm_plane_create_zpos_immutable_property().
>
> stacking of overlay (and or) scanout planes?
Yeah might be better to drop the "overlay" here, this is for planes in
general. Overlay vs. other planes is really only relevant for the
legacy ioctls, to make sure they know which plane to pick. Otherwise
there's nothing special with them.
-Daniel
>
>
> > *
> > * 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.
> > *
> > * See drm_plane_create_zpos_property() and
> > * drm_plane_create_zpos_immutable_property() for more details.
> > --
> > 2.23.0
> >
> >
>
> --
> Marius Vlad
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
