This will let compositors know if changing adaptive_sync state has any
chance of working. When false, then the current state is the only
supported state, including if adaptive_sync is currently enabled as is
the case for Wayland and X11 backends.
When true, changing state might succeed, but no guarantee is made. It
just indicates that the backend does not already know it to be
impossible.
We don't need to process all events, only those that come from the host
compositor. This also avoids running user event handlers while in the
middle of committing an output.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3857
Some DRM devices are not KMS-capable. DRM card nodes (also
known as DRM primary nodes) are created for render-only devices
as well. Let's just use "KMS" everywhere instead of "DRM" and
"DRM card".
This commit fixes the following interaction:
1) The host compositor sends a configure sequence for an output.
2) Before handling it, the guest compositor disables and immediately
re-enables the output.
3) The guest compositor tries to ack the configure event from step 1
which isn't relevant anymore after unmapping and re-initialization.
Instead, ignore all configure events after unmapping until we're sure
the host compositor has processed the unmapping.
Also see
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/108.
- Reset all variables representing an initialized xdg_toplevel's state
on unmap.
- Send an initial commit only when an output is about to be enabled.
- If an output isn't configured yet, don't commit a buffer.
If the guest compositor disabled an output and then immediately
committed another state, we would perform a commit with a null buffer,
which is against the protocol, as the host compositor expects an
initial commit with no buffer at all.
Even if the backend advertises dri3 support, querying the DRM FD may fail.
Instead of returning early, the backend creation process must continue because
shm might be supported.
Our multi-gpu path currently needs to blit a buffer in order to have a
primaryfb to add to the commit. This is expensive, and we skip it
entirely during test commits. This in turn also means that we skip tests
commits entirely for such outputs, outside our own basic tests.
Backend-wide commits missed this check, and tried to perform test
commits for multi-gpu outputs despite no primaryfb having been attached,
making them always fail. Add the same exception as we have in the
per-connector commit-test.
When a compositors submits a wlr_output_state with
WLR_OUTPUT_STATE_ADAPTIVE_SYNC_ENABLED set and
adaptive_sync_enabled = false on an output which doesn't support
adaptive sync, we'd fail the commit. Fix this.
This bug was previously hidden because wlr_output_commit() drops
no-op changes from wlr_output_state.committed.
After disabling a connector, we need to cleanup the connector to
teardown the surfaces and unlock the FBs.
Move this logic into drm_connector_apply_commit() so that it's
applied when drm_commit() is called from somewhere else than
drm_connector_commit_state().
There is some duplicated logic between these two functions.
The commit codepath was calling the test function before doing the
real commit, so this also saves an unnecessary test-only commit
when performing a real commit.
This centralizes logic common for both the atomic and libliftoff
backends. Additionally, a struct will make it easier to implement
multi-connector commits (since it can be stored in an array).
In [1] we discovered a bug where wlr_drm_connector_state.primary_fb
would not be set up correctly because drm_connector_alloc_crtc() was
called after drm_connector_state_init(). This is tricky to discover,
so instead assert() that we have a usable CRTC by the time
drm_connector_state_init() is called.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4569
