This is a set of well-known KMS standard properties, either used
by libliftoff itself or commonly used by compositors. Adding
special cases for these allows us to access them without having
to iterate over a list.
This roughly improves performance by ~50% when leaving out the
atomic test-only commits.
Closes: https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/1
Previously, we would reallocate when any CRTC_* property changes. This
leads to unnecessary reallocations when a plane moves or resizes. Cursor
movements would reallocate on every update, for example.
What we really care about is if a layer's intersection status with
another plane changes, so do that.
`gcc-14` added a new `-Wcalloc-transposed-args` warning recently. It
detected minor infelicity in `calloc()` API usage in `libliftoff`:
../layer.c: In function 'liftoff_layer_create':
../layer.c:20:48: error: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in t
ument [-Werror=calloc-transposed-args]
20 | layer->candidate_planes = calloc(sizeof(layer->candidate_planes[0]),
| ^
../layer.c:20:48: note: earlier argument should specify number of elements, later size of each element
Right now, compositors are expected to query liftoff_layer_get_plane_id to
decide whether a layer needs to be composited.
However there are cases where a layer has no plane, but still doesn't need
composition (e.g. when FB_ID is zero or when alpha is zero, in the future when
the layer is out of CRTC bounds etc).
Add a new API to make users' life simpler.
Closes: https://github.com/emersion/libliftoff/issues/54
Similar to reuse log print debug information only when the priority of a layer
changes not whenever priority gets updated but without change.
Otherwise the debug log is spammed (depending on LIFTOFF_PRIORITY_PERIOD).
This would previously result in a crash:
==169727==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x7f3e0c4d7dc7 bp 0x7ffc97f8aff0 sp 0x7ffc97f8afc0 T0)
==169727==The signal is caused by a READ memory access.
==169727==Hint: address points to the zero page.
#0 0x7f3e0c4d7dc6 in layer_update_priority ../subprojects/libliftoff/layer.c:152
#1 0x7f3e0c4d3a4c in update_layers_priority ../subprojects/libliftoff/alloc.c:573
#2 0x7f3e0c4d3d7f in liftoff_output_apply ../subprojects/libliftoff/alloc.c:590
…
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
