| Message ID | T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v6] drm: two planes with the same zpos have undefined ordering | expand |
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 > >
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.