has_composited_layer_on_top is now less strict and performs plane intersection
checks before returning true.
This allows for more layers to be assigned to planes, the relevant tests have
been enabled.
References: https://github.com/emersion/libliftoff/issues/3
This will be useful for implementing optimizations in case planes don't collide.
In these cases we can ignore some zpos constraints.
References: https://github.com/emersion/libliftoff/issues/3
This test makes sure composited layers make layers underneath fall back to
composition too, in a transitive manner. That is, if plane A is under plane B
which is itself under plane C, plane A falling back to composition means that
both planes B and C fall back to composition too (even if C isn't directly
underneath A).
If a layer cannot be mapped to a plane, make it so all layers under it also fail
plane allocation so that they can be properly composited on the primary plane.
A test was incorrect and has been fixed. Another test had two possible solutions
and has been updated with the one libliftoff yields.
zpos-3x maps three layers to primary, cursor and one of the overlays planes.
zpos-4x-partial sets up 4 layers but is only able to find a plane for 3 layers,
because ordering between the two overlay planes is undefined.
When testing the library, the libdrm dependency is swapped with a mock libdrm.
The test sets up the mock libdrm's internal state and then runs the test.
This commit adds special handling for the layer zpos property. Setting it won't
forward it to KMS, instead it will be handled internally.
The plane zpos (either retrieved from KMS if the property is supported, or
guessed from the plane type and ID) is checked during plane allocation to have
the same ordering as the layer zpos. This adds more constraints to the
allocation.
Note that the new constraints are too strict. In case two layers don't overlap,
there's no need for one plane to be on top of the other. See [1].
Also, the new constraints don't account for underlay planes [2].
[1]: https://github.com/emersion/libhwc/issues/3
[2]: https://github.com/emersion/libhwc/issues/7
Closes: https://github.com/emersion/libhwc/issues/4
In case we can't do better than the current best allocation even if we manage
to allocate all remaining planes, we bail out early. However the bailout
condition was incorrect and didn't account for the current score.
Sometimes the properties applied on a layer are missing on a plane. Instead of
making the whole allocation fail, just mark the plane as incompatible with the
layer.
Given a primary plane with zpos=0 and overlay planes with zpos 1 2, we want
first to allocate the primary plane, then the furthest overlay plane, then the
remaining one: 0 2 1.
References: https://github.com/emersion/libhwc/issues/3
If zpos is present, instead of guessing the zpos from the plane type, just use
it. If two planes have the same zpos, we consider their relative position as
undefined.
We don't handle the case where some planes have zpos set but some others don't.
References: https://github.com/emersion/libhwc/issues/4
Many drivers don't expose the zpos plane property. We can guess it from the
plane type though: primary, overlay, cursor. Except some drivers expose
underlays too: underlays, primary, overlay, cursor. Underlay planes don't have a
special type, they are just marked as overlays. To detect them, check whether
their plane ID is less than the primary plane ID.
References: https://github.com/emersion/libhwc/issues/3
