We were checking whether the damage region was empty before
clipping. However a non-empty damage region can become empty after
clipping. Instead, check whether the clipped region is empty.
Fixes: 4339c37f99 ("backend/drm: clip FB damage")
Currently the headless backend does not actually implement the
wlr_output_test function, causing tests containing output state
unsupported by the headless backend to succeed while committing the same
state will always fail.
This commit fixes that by actually hooking up the already exisiting test
function.
References: https://codeberg.org/river/river/issues/1154
Enable scene-tree direct scanout of a single buffer with various options
for scaling and source crop. This is intended to support direct scanout
for fullscreen video with/without scaling, letterboxing/pillarboxing
(e.g. 4:3 content on a 16:9 display), and source crop (e.g. when
1920x1088 planes are used for 1920x1080 video).
This works by explicitly specifying the source crop and destination box
for the primary buffer in the output state. DRM atomic and libliftoff
backends will turn this into a crop and scale of the plane (assuming the
hardware supports that). For the Wayland/X11/DRM-legacy backends I just
reject this so scanout will be disabled.
The previous behaviour is preserved if buffer_src_box and buffer_dst_box
are unset: the buffer is displayed at native size at the top-left of the
output with no crop.
The change to `struct wlr_output_state` makes this a binary breaking
change (but this works transparently for scene-tree compositors like
labwc after a recompile).
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: 514c4b4cce01 ("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.
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.
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.
itycodes
Simon Ser
Peng Liu
Isaac Freund
David Turner
Kenny Levinsen
Kirill Primak
YaoBing Xiao
Alexander Orzechowski
Dudemanguy
project-repo