On Tue, 10 Sep 2019 11:20:16 +0000 Simon Ser <cont...@emersion.fr> wrote:
> On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > > > On Tue, 10 Sep 2019 10:09:55 +0000 > > Simon Ser cont...@emersion.fr 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. > > > > > > Signed-off-by: Simon Ser cont...@emersion.fr > > > > > > --------------------------------------------- > > > > > > Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake. > > > drivers/gpu/drm/drm_blend.c | 8 ++++---- > > > 1 file changed, 4 insertions(+), 4 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(). > > > - > > > - pixel blend mode: > > > - Pixel blend mode is set up with > > > drm_plane_create_blend_mode_property(). > > > > Hi, > > > > this seems to contradict what the docs say in another place: > > Except this comment is about drm_plane_state.zpos, an internal DRM > property. This is not about the zpos property itself. Hi, then I'm very confused. What's the difference? The text you are changing was specifically added to explain uAPI behaviour, that is, what the userspace sees and does with the zpos property in uAPI. Having two conflicting pieces of documentation is confusing, especially when it is not absolutely clear which one is for driver implementors and which one for uAPI consumers, or that one must ignore the other doc depending on who you are. > The comment was introduced in v2 of [1], although the motivation for > the change isn't documented. > > [1]: https://patchwork.freedesktop.org/series/13528/#rev2 That does not look like the comment you are changing. Wait, which one is "this comment"? > > 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. > > > > See drm_plane_create_zpos_property() and > > drm_plane_create_zpos_immutable_property() for more details. > > > > from > > https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference Me and others have taken the above to document uAPI. How could that not be the case? Is it wrong for userspace to assume that plane object ID order reflects the plane stacking order? Weston does not do this yet, but since we just recently found the above comment, we planned to make use of it. Actually, if the ID ordering is true, then the DRM core could always expose the zpos property as immutable to userspace, just manufacture it from object IDs if nothing is set by a driver explicitly. Or is the comment about object IDs wrong and should be changed to say the opposite? Thanks, pq
pgpDN4b3O_DLX.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
