[v4] drm: two planes with the same zpos have undefined ordering

[Pekka Paalanen]

On Tue, 8 Oct 2019 11:59:04 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Mon, Sep 30, 2019 at 10:07:07AM +0300, Pekka Paalanen wrote:
> > On Sun, 29 Sep 2019 20:30:44 +0000
> > Simon Ser <contact at emersion.fr> wrote:
> >   
> > > Hi,
> > >   
> > > > 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 a lot for your feedback James, that's exactly what I was looking for.
> > > Both of these use-cases make sense to me.
> > > 
> > > I think user-space should be prepared to handle identical immutable zpos values.
> > > Pekka and Daniel, thoughts?  
> > 
> > Hi,
> > 
> > given those explained use cases, sure, I agree.
> >   
> > > In any case, this doesn't change the patch itself. Probably something worth
> > > mentionning in the commit message.  
> > 
> > Yes, recording these use cases would be very nice.  
> 
> There's a lot more hw that does the same tricks (qualcom is one for sure).
> Imo before we encode this we should make sure that:
> a) everyone is happy with this new uapi

Sorry, what new UAPI?

We're just trying to make the documentation match what currently
happens, right?


Thanks,
pq


> b) drivers are consistent
> c) maybe even testcases in igt
> d) definitely an open source user
> e) no breaking of existing userspace
> 
> I.e. definitely a separate patch.
> -Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20191008/fa414a9e/attachment-0001.sig>