The invalid_destroy and invalid_unlock protocol errors aren't currently
sent by wlroots and instead left up to the compositor. However, we can
handle these as well without much additional complexity.
This also adds a missing wl_resource_destroy() call if the lock is inert
in lock_handle_unlock_and_destroy().
We only need it for one thing: gamma size. Moreover, some bits in
the drmModeCrtc will become out-of-date, for instance the current
mode, so let's avoid caching the whole struct and only keep what
we know won't change.
Instead of having a pending_fb field on the struct wlr_drm_plane,
move it to struct wlr_drm_connector_state. That way, there's no
risk having a stale pending FB around: the state doesn't survive
across tests and commits.
The cursor is a special case because it's disconnected from the
atomic state: the wlr_backend_impl.set_cursor hook sets the cursor
for the next commit. Move the field to
wlr_drm_connector.cursor_pending_fb.
We'll move the pending primary FB into the connector state in the
next commit, dropping wlr_drm_plane.pending_fb in the process.
Introduce a dedicated field for the cursor, which has to be managed
in a special way due to our set_cursor API.
This avoids re-building the whole project when switching one
Meson option. This shrinks down the compiler invocation command
line, making it more readable and making it easier to inspect
which flags are passed in (the generated file can be opened).
Additionally this is more consistent with our external feature
handling, which uses <wlr/config.h> already.
The Vulkan spec doesn't guarantee that the driver will wait for
implicitly synchronized client buffers before texturing from them.
radv happens to perform the wait, but anv doesn't.
Fix this by extracting implicit fences from DMA-BUFs, importing
them into Vulkan as a VkSemaphore objects, and make the render pass
wait on these VkSemaphores.
wlroots uses "// private state" comments to denote structure fields
which shouldn't be accessed by compositors, so let's drop
wlr_output_layout_output_state and inline its fields into
wlr_output_layout_output; this also simplifies layout output creation.
struct wlr_vk_format_props contains a mix of properties for shm
and dmabuf, and it's not immediately clear which fields are for
which kind of buffer. Use a nested struct to group the fields.
Query the formats at init time, then forget about the renderer.
This will allow wl_drm to be created with a list of formats instead
of a renderer, and will behave better after a GPU reset.
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
Some compositors may want to use the linux-dmabuf-v1 implementation
with a completely custom renderer. Add a function to create the
global with a default feedback.
Right now the Vulkan renderer blocks until the frame is complete
after rendering. This is necessary because Vulkan doesn't
interoperate well with implicit sync we use everywhere else.
Use the new kernel API to import a sync_file into a DMA-BUF to
avoid blocking.
We need to wait for the pending command buffer to complete before
re-using stage buffers. Otherwise we'll overwrite the stage buffer
with new contents before the texture is fully uploaded.
We need to wait for any pending command buffer to complete before
we're able to fully destroy a struct wlr_vk_texture: the Vulkan
spec requires the VkDescriptorSet to be kept alive.
So far we've done this in vulkan_end(), after blocking until the
command buffer completes. We'll soon stop blocking, so move this
logic in get_command_buffer(), where we check which commands buffers
have completed in a non-blocking fashion.
vkCmdCopyBufferToImage requires that the buffer offset be a multiple
of the texel block size, which for single plane uncompressed formats
is the same as the number of bytes per pixel. This commit adds an
alignment parameter to vulkan_get_stage_span which ensures that the
provided span (and the sequence of image copy operations derived which
use it) have this alignment.
