The default limit of 1ms might be too short if the compositor
calls liftoff_output_apply() early in the vblank cycle, or too
long if the refresh rate is high. The compositor is in a better
spot to decide how much time should be spent on atomic tests, so
add an option for that.
Closes: https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/78
When the caller wants to perform a modeset, they will need to pass
DRM_MODE_ATOMIC_ALLOW_MODESET in the atomic commit flags, otherwise the driver
will fail the commit. libliftoff also needs to provide these flags in its
test-only commits.
In file included from ../log.c:4:
In file included from ../include/log.h:4:
In file included from ../include/libliftoff.h:8:
/usr/local/include/xf86drmMode.h:551:19: error: zero size arrays are an extension [-Werror,-Wzero-length-array]
uint32_t lessees[0];
^
/usr/local/include/xf86drmMode.h:558:19: error: zero size arrays are an extension [-Werror,-Wzero-length-array]
uint32_t objects[0];
^
test/bench.c:99:16: error: use of undeclared identifier 'CLOCK_MONOTONIC'
clock_gettime(CLOCK_MONOTONIC, &start);
^
test/bench.c:106:16: error: use of undeclared identifier 'CLOCK_MONOTONIC'
clock_gettime(CLOCK_MONOTONIC, &end);
^
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
This is a pretty basic benchmark measuring the time spent in
liftoff_display_apply.
The current behaviour tries to reproduce the worst case scenario: layers don't
intersect and one plane is incompatible with all layers.
