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?
In any case, this doesn't change the patch itself. Probably something worth mentionning in the commit message.