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?
> *
> * 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
