With these flags API consumers can optimize the depiction of libliftoff's debug
log.
For now the two flags for a section start and end are introduced. It is
guaranteed that one section always ends before the next one begins.
Is no callback function setup section starts and ends in the default stderr
output will be marked with an empty line.
BREAKING CHANGE: The signature of the log callback changes.
Instead of exposing to consumers write streaming log data into a per-device
buffer that gets created on request and destroyed after the buffer has been
written to the log.
Passing a NULL string to the internal continuous log function triggers a write
of the buffer to the log.
BREAKING CHANGE: continuous log function is moved from log header to private
header.
Enumerating all planes to be disabled makes the log unnecessary
sparse. Instead just list all planes in a single line.
For that introduce new API function to log something without line
break in the end and adapt the log callback function pointer.
BREAKING CHANGE: log callback function arguments change.
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
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
