This commit adds basic per-property change tracking.
When only FB_ID has changed, we try to re-use the previous allocation. If that
fails, go on with regular plane allocation.
Closes: https://github.com/emersion/libliftoff/issues/6
Instead of baking plane allocation constraints in output_choose_layers, extract
constraints checked at each step in check_layer_plane_compatible and final
constraints in check_alloc_valid.
This lets the library user define a layer where composition will happen. At the
moment there can be at most one composition layer per output, on the primary
plane. It should be possible to remove these restrictions in the future if
desirable.
The composition layer will be put on a plane if and only if composition is
needed.
The compositor needs to know where composited layers will be blended to resolve
zpos conflicts.
Closes: https://github.com/emersion/libliftoff/issues/9
If a plane was previously enabled on another CRTC, we need to set its CRTC_ID to
zero. Otherwise atomic commits fail with:
[drm:drm_atomic_check_only [drm]] [PLANE:31:primary A] CRTC set but no FB
Rename has_composited_layer_on_top to has_composited_layer_over. This is more
consistent with has_allocated_layer_over.
While at it, add a comment to explain why has_allocated_layer_over is named like
so.
Make sure we don't use planes with lower zpos for layers over the previous ones,
unless there is no collision.
This adds the last intersection check.
Closes: https://github.com/emersion/libliftoff/issues/3
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
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.
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
