wlr_multi_backend sorts the states it is given and tries to perform
sequential backend-wide commits for each sub-backend with the states
that belong to it.
It did not manage the index correctly for the next iteration, so given N
states for a backend it would perform N backend-wide commits.
Clarify the logic by calculating a length rather than an end pointer and
update the index after each iteration.
This piece of code checks for multi-GPU renderer support, so it
needs to run after the renderer is initialized.
Fixes: 514c4b4cce ("backend: add timeline feature flag")
Closes: https://github.com/swaywm/sway/issues/8382
The output feature flag has a flaw: it's not possible to check
whether the backend supports timelines during compositor
initialization when we need to figure out whether we want to enable
the linux-drm-syncobj-v1 protocol.
Introduce a backend-wide feature flag to indicate support for
timelines to address this defect.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3904
After a connector scan, new connectors might have appeared and old ones
gone away. At this point, old CRTC allocations are already gone, while
new allocations are not yet needed. Skip the call.
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.
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.
