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.
Logigng the list of planes being disabled at the beginning of an apply does not
really give useful information.
Planes are disabled (and by that become in theory ready for layer-assignment)
if they do not have a layer associated at the moment or if they are compatible
with the output.
That is uninteresting since in this list the subset of planes that are
compatible with the output stay constant. And while the subset of planes being
reset not compatible with the output might vary from apply to apply it is also
of less interest since by definition they are not compatible with what the
apply is about.
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.
Compositors need to drive multiple connectors, each with its own vblank timings.
For each device, there's one separate rendering loop per output.
It's not possible to call liftoff_device_apply each time we want to submit a new
frame to one output, because this could touch another's output state, submitting
a new frame there in the process. When the other output will submit a new frame,
it'll get EBUSY (can't submit two frames without waiting for vblank).
Closes: https://github.com/emersion/libliftoff/issues/21
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
