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.
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
