Based on five calls:
wlr_render_timer_create - creates a timer which can be reused across
frames on the same renderer
wlr_renderer_begin_buffer_pass - now takes a timer so that backends can
record when the rendering starts and finishes
wlr_render_timer_get_time - should be called as late as possible so that
queries can make their way back from the GPU
wlr_render_timer_destroy - self-explanatory
The timer is exposed as an opaque `struct wlr_render_timer` so that
backends can store whatever they want in there.
Many issues here:
- wlr_output_cursor_set_buffer() takes a buffer already scaled for
the output, not a buffer with scale=1.
- wlr_output_cursor.{width,height,hotspot_x,hotspot_y} are in output
buffer coordinates.
- render_cursor_buffer() had hardcoded no-ops for scale and
transform, instead of using the cursor surface's.
Fixes: b64e7e88bf ("output: add output_cursor_set_texture()")
If a modeset contains a render format change, use that instead of
the current one stored in wlr_output.render_format.
This fixes render_bit_depth configuration not being applied without
a second modeset in Sway.
The Wayland, X11 and headless backends don't really care about the
cursor size. We were picking a size identical to the texture size
in that case. This is incorrect for LoDPI cursor textures on HiDPI
outputs: in that case, we need to scale up the cursor texture.
Fixes the cursor being chopped off under the Wayland backend with
scale > 1.
Add a src_box state field. Use the SRC_* KMS props in the DRM
backend, reject the layers in the Wayland backend (for now, we can
support it later via viewporter).
wlr_output is not well-suited to checking whether direct scan-out
is happening or not. Compositors may want to use their own external
swapchains, for instance.
Additionally, ab7eabac84 ("output: leverage
wlr_output_configure_primary_swapchain()") makes it so
output_basic_test() is called before the output swapchain is
initialized, resulting in false positives.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3620
This allows callers to set a destination size different from the
buffer size to scale them.
The DRM backend supports this. The Wayland backend doesn't yet
(we'd need to wire up viewporter).
- Simplifies the backends
- Avoids having two ways to do the same thing: previously one could
disable a layer by either omitting it from wlr_output_state.layers,
or by passing a NULL buffer
- We can change our mind in the future: we can allow users to omit
some layers and define a meaning without breaking the API.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4017#note_1783997
Replace our current logic to setup the primary swapchain with
wlr_output_configure_primary_swapchain().
- Removes some code, reducing duplication
- Stop overwriting wlr_output.swapchain with a yet-to-be-tested
swapchain: remove the error_destroy_swapchain label.
We've had this struct for a while. It'd be useful for compositors
if they want to manage the swap chains themselves instead of being
forced to use wlr_output's. Some compositors might also want to use
a swapchain without an output.
This is based on previous work [1] [2].
This new API allows compositors to display buffers without needing to
perform rendering operations. This API can be implemented on Wayland
using subsurfaces and on DRM using KMS planes.
Compared to [1], this approach leverages wlr_addon_set to let backends
attach their own private state to layers, removes the pending
state (necessary for interop with wlr_output_commit_state()) and
enum wlr_output_layer_state_field.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/1985
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3447
In output_ensure_buffer() we create a swapchain and attach an empty
buffer to the output if necessary. We do that during the first commit.
This is fine when the first commit enables the output, however this breaks
when the first commit disables the output. A commit which disables an
output and has a buffer attached is invalid (see output_basic_test()), and
makes the DRM backend crash:
00:00:00.780 [wlr] [backend/drm/drm.c:622] connector eDP-1: Turning off
../subprojects/wlroots/backend/drm/drm.c:652:44: runtime error: member access within null pointer of type 'struct wlr_drm_crtc'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2524==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f22e894afc1 bp 0x7ffe1d57c550 sp 0x7ffe1d57c420 T0)
==2524==The signal is caused by a READ memory access.
==2524==Hint: address points to the zero page.
#0 0x7f22e894afc1 in drm_connector_commit_state ../subprojects/wlroots/backend/drm/drm.c:652
#1 0x7f22e894b1f5 in drm_connector_commit ../subprojects/wlroots/backend/drm/drm.c:674
#2 0x7f22e89e8da9 in wlr_output_commit_state ../subprojects/wlroots/types/output/output.c:756
#3 0x555ab325624d in apply_output_config ../sway/config/output.c:517
#4 0x555ab31a1aa1 in handle_new_output ../sway/desktop/output.c:974
#5 0x7f22e9272f6d in wl_signal_emit_mutable (/usr/lib/libwayland-server.so.0+0x9f6d)
#6 0x7f22e899b012 in new_output_reemit ../subprojects/wlroots/backend/multi/backend.c:161
#7 0x7f22e9272f6d in wl_signal_emit_mutable (/usr/lib/libwayland-server.so.0+0x9f6d)
#8 0x7f22e895a153 in scan_drm_connectors ../subprojects/wlroots/backend/drm/drm.c:1488
#9 0x7f22e893c2e4 in backend_start ../subprojects/wlroots/backend/drm/backend.c:24
#10 0x7f22e892ed00 in wlr_backend_start ../subprojects/wlroots/backend/backend.c:56
#11 0x7f22e8999b83 in multi_backend_start ../subprojects/wlroots/backend/multi/backend.c:31
#12 0x7f22e892ed00 in wlr_backend_start ../subprojects/wlroots/backend/backend.c:56
#13 0x555ab317d5cc in server_start ../sway/server.c:316
#14 0x555ab317748d in main ../sway/main.c:400
#15 0x7f22e783c28f (/usr/lib/libc.so.6+0x2328f)
#16 0x7f22e783c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
#17 0x555ab3134c84 in _start (/home/simon/src/sway/build/sway/sway+0x377c84)
Fixes: 3be6658ee7 ("output: allocate swapchain on first commit")
Closes: https://github.com/swaywm/sway/issues/7373
The backend no longer changes the output state behind the
compositor's back. Instead, compositors can listen to the "commit"
event and check for WLR_OUTPUT_STATE_ENABLED/WLR_OUTPUT_STATE_MODE.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2300
If a fixed mode matching the user requirements is available, use
that. This avoids generating the mode with GTF or CVT in the DRM
backend, and instead uses mode timings advertised by the output.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3514
On first commit, require a new buffer if the compositor called a
mode-setting function, even if the mode won't change. This makes it
so the swapchain is created now.
Stop trying to check whether the backend supports buffer-less modesets
because that makes everything more complicated. For instance, the
DRM backend doesn't need a new buffer if the previous DRM master left
the output enabled.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3499
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3502
Some compositors want to have full control over the buffers attached
to the output, and don't want to use the internal swapchain. Such
compositors include KWinFT (allocates its buffers on its own) and
gamescope (uses a headless output without any buffers).
Let's just make output_ensure_buffer() a no-op in that case.
When starting up, the compositor might call wlr_output_set_mode()
with a mode which is already the current one. wlroots will detect
this and make the wlr_output_set_mode() call a no-op. During the
next wlr_output_commit() call, wlroots will perform an atomic
commit without the ALLOW_MODESET flag.
This is an issue, because some drivers need ALLOW_MODESET even if
the mode is the same. For instance, if the FB stride or modifier
changed, some drivers require a modeset.
Add a new flag "allow_artifacts" which is set when the compositor
calls mode-setting functions. Use this flag to figure out whether
we want to perform atomic commits with ALLOW_MODESET.
(The name "allow_artifacts" is picked because ALLOW_MODESET is a
misnomer, see [1].)
[1]: https://patchwork.freedesktop.org/patch/505107/
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3499
In wlr_output_attach_render(), stop setting
wlr_output.pending.buffer. This removes one footgun: using the
wlr_buffer at that stage is invalid, because rendering operations
haven't been flushed to the GPU yet. We need to wait until
output_clear_back_buffer() for the wlr_buffer to be used safely.
Instead, set wlr_output.pending.buffer in wlr_output_test() and
wlr_output_commit().
Additionally, move the output_clear_back_buffer() from
wlr_output_commit_state() to wlr_output_commit(). This reduces the
number of calls in the failure path.
We can just use pending.buffer instead. It's completely fine to
call wlr_swapchain_set_buffer_submitted() with a buffer which
doesn't come from the swapchain, in which case it's a no-op.
This is documented to reset the gamma LUT, but we don't handle this
properly.
While at it, make sure we leave wlr_output.pending in a good state
on allocation failure.
If the first test in output_ensure_buffer() fails with modifiers we
replace the swapchain with a modifierless swapchain and try again.
However if that fails as well the output is currently stuck without
modifiers until the next modeset.
To fix this, destroy the modifierless swapchain if the test using it
fails. The next output_attach_back_buffer() call will create a swapchain
that allows modifiers when needed.
When using direct scanout back_buffer is NULL. We'd emit a commit
event with WLR_OUTPUT_STATE_BUFFER set but with a NULL buffer field,
which is non-sensical.
The previous wlr_output_cursor_set_image() allows setting a NULL buffer for the
cursor to hide it. This functionality was used by sway to hide the cursor,
restore the original semantics by allowing NULL buffers again by avoiding the
wlr_buffer allocation in case we have NULL pixels and handing a NULL wlr_buffer
to wlr_output_cursor_set_buffer().
Before calling wlr_output_impl.{test,commit}, perform a cheap
comparison between the current and candidate state. Unset any
fields which didn't change.
This refactors output_ensure_buffer() to not mutate the state passed,
making the previous subtle behavior much more explicit.
Fixes: d483dd2f ("output: add wlr_output_commit_state")
Closes: #3442
This allows the make/model/serial to be NULL when unset, and allows
them to be longer than the hardcoded array length.
This is a breaking change: compositors need to handle the new NULL
case, and we stop setting make/model to useless "headless" or
"wayland" strings.
When calling wlr_output_test an empty buffer might be created. This implicitly
changes the pending state of the output. Ensure that such a change is only
temporarily and clear such an empty buffer before returning the test result.
wlroots picks names for all outputs, but it might be desirable for
compositor to override it.
For instance, Sway will use a headless output as a fallback in
case no outputs are connected. Sway wants to clearly label the
fallback output as such and label "real" headless outputs starting
from HEADLESS-1.
This allows output commit listeners to access the newly committed
buffer. Currently wlr_output.front_buffer is used but it'll get
removed in the next commit.
DRM formats with an empty modifier list are invalid. Instead of
emptying the list, reduce it to { INVALID }.
Add a check to make sure the renderer and backend support implicit
modifiers, so that we don't fallback on e.g. Vulkan.
Closes: https://github.com/swaywm/sway/issues/6692
This allows compositors to get primary formats without manually
calling wlr_output_impl.get_primary_formats.
For example, the Sway patch for linux-dmabuf feedback [1] needs
this.
[1]: https://github.com/swaywm/sway/pull/6313
Sometimes we were calling wlr_output_impl.set_cursor with a NULL
buffer, but we weren't clearing wlr_output.cursor_front_buffer.
Avoid leaving a dangling buffer behind.
Introduce a helper function output_set_hardware_cursor which calls
wlr_output_impl.set_cursor and keeps cursor_front_buffer in sync.
All graphics drivers supporting cursor planes support ARGB8888,
the default cursor format, so this fallback is almost certainly
unused.
Essentially all cursor themes use alpha transparency to make it
clearer where relative to the screen content the cursor hotspot is.
It is better to fall back to a slightly slower software cursor than
it is to fall back to the opaque square that is a hardware cursor
without an alpha channel.
This change introduces new double buffered state to the wlr_output,
corresponding to the buffer format to render to.
The format being rendered to does not control the bit depth of colors
being sent to the display; it does generally determine the format with
which screenshot data is provided. The DRM backend _may_ sent higher
bit depths if the render format depth is increased, but hardware and
other limitations may apply.
Most (and possibly all) compositors using wlroots only ever render
fully opaque content. To provide better performance, this change
switches the default format used by wlr_output buffers from
ARGB8888 to the opaque XRGB8888.
Compositors like mutter, kwin, and weston already default to
XRGB8888, so this change is unlikely to expose any new bugs in
underlying drivers and hardware.
This does not affect the hardware cursor's buffer format, which is
still ARGB8888 by default.
As part of this change, the X11 backend (which does not support
changing format at runtime) now picks a true color, 24 bit depth
visual (i.e. XRGB8888) instead of a 32 bit depth (ARGB8888) one.
This makes it possible for the two functions using output_pick_format
(output_pick_cursor_format and output_create_swapchain) to select
different buffer formats.
The backend and renderer don't directly interact together, so there's
no point in checking that their buffer caps intersect. What we want to
check is that:
- The backend and allocator buffer caps are compatible, because the
backend consumes buffers to display them.
- The renderer and allocator buffer caps are compatible, because the
renderer imports buffers to sample them or render to them.
For instance, when running with the DRM backend and the Pixman renderer,
the (backend & renderer) check will fail because backend = DMABUF and
renderer = DATA_PTR.
Alexander Orzechowski
Simon Ser
Rose Hudson
Alexander Orzechowski
bi4k8
Kirill Primak
Isaac Freund
Rouven Czerwinski
Roman Gilg
Manuel Stoeckl