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.
This fixes a misunderstanding of the DRM API. Only a regular commit applies
properties.
Fixes: b16078769e ("test/libdrm_mock: a test-only commit applies properties")
The previous mock library assumed the DRM client would always set all
properties in the atomic request. However, if a previous test-only commit
has set a property, there's no need to set it again.
Accomodate for this in libdrm_mock. This will be useful when we'll skip
setting properties that haven't changed in libliftoff.
References: https://github.com/emersion/libliftoff/issues/37
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
