Up until now only the DRM backend required an output commit after
updating the cursor. Unify this for all backends, because:
- Screen capture can now catch cursor updates listening for output
commits
- In the future we want to make the cursor a regular wlr_output_layer,
which would need an output commit to be updated anyways
The page_flip can be destroyed, but it is unconditionally accessed later
on when setting present_flags. Fix this by simply setting the
present_flags before the page_flip gets destroyed.
../backend/drm/drm.c:415:49: error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
415 | layer->candidate_planes = calloc(sizeof(bool), drm->num_planes);
| ^~~~
../backend/drm/drm.c:1435:24: error: incompatible types when returning type ‘_Bool’ but ‘struct wlr_drm_connector *’ was expected
1435 | return false;
| ^~~~~
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.
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
Use the same logic for cursor FBs as we currently use for primary
FBs. This also fixes the same bug as [1] but in a different, more
robust way.
The new logic integrates better with atomic and will be required
anyways in the future when set_cursor will be superseded by a better
API.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4577
With the following sequence of events, the cursor FB fields could
end up being all set to NULL while the cursor is enabled:
1. set_cursor is called, conn->cursor_pending_fb is set to a FB
pointer.
2. The output is committed with a buffer. crtc->cursor->queued_fb
is set to the FB pointer, conn->cursor_pending_fb is reset to
NULL. A page-flip event is expected in the future.
3. The output is committed with a modeset before the page-flip
event is triggered. crtc->cursor->queued_fb is reset to NULL.
At this point all of crtc->cursor->current_fb,
crtc->cursor->queued_fb and conn->cursor_pending_fb are NULL which
is a bogus state when the cursor plane is enabled.
To avoid this issue, avoid overwriting crtc->cursor->queued_fb
with a NULL pointer on commit. The cursor logic still isn't great,
but let's keep a rework of that for a separate patch.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3734