On Tue, 8 Oct 2019 11:59:04 +0200 Daniel Vetter <daniel@xxxxxxxx> 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@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. > > 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
Attachment:
pgp40ev3gnk7C.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
