It is helpful for debugging to know in which state the available planes on an
output are when a layout is applied that leads to a change.
For that log all planes that are compatible with the output. Currently disabled
planes have multiple properties logged per line to keep the log short.
On debug verbosity logging every reuse of planes is spamming the log making it
difficult to debug the process.
With this patch only the change of reusing the same allocation is logged and
how often the allocation was reused after this changed back again.
Start from scratch since we may be able to come up with a better allocation
(if the layer made another layer fall back to composition for instance).
Closes: https://github.com/emersion/libliftoff/issues/30
Keep track of the number of layer updates per 60 page-flips.
We could implement a more fine-grained tracking, for instance with a sliding
window. However it's a lot more complex than the current solution and the gains
are not clear. I'd prefer to keep the current solution and experiment with other
solutions once we have a good test-bed.
References: https://github.com/emersion/libliftoff/issues/22
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
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
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 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
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
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
