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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 29 Sep 2019 20:30:44 +0000
Simon Ser <contact@xxxxxxxxxxx> 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.


Thanks,
pq

Attachment: pgpZHQgiaftaA.pgp
Description: OpenPGP digital signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux