This is a first step towards moving texture uploading out of
wlr_compositor.
This commit allows compositors to opt-out of the texture uploading
by passing a NULL wlr_renderer. An immediate user of this is
gamescope, which currently implements a stub wlr_renderer just to
make wlr_compositor happy.
Let's just forward-declare struct wlr_backend instead.
We need to fixup the Vulkan renderer: it needs makedev(), which
got included by chance via <wlr/backend.h> → <wlr/backend/session.h>
→ <libudev.h>.
This can be used to know when wlr_xwayland_server decides to start
a new Xwayland process. At that point the wl_client has already
been created but the Xwayland process hasn't been started yet.
Up until now, wlr_backend_autocreate() created the wlr_session and
then stuffed it into struct wlr_multi_backend so that compositors
can grab it later.
This is an abuse of wlr_multi_backend and the wlr_backend API:
wlr_backend_get_session() and wlr_multi_backend.session only exist
to accomodate the needs of wlr_backend_autocreate(). What's more,
the DRM and libinput backends don't implement
wlr_backend_impl.get_session.
Instead, return the struct wlr_session to the compositor in the
wlr_backend_autocreate() call. wlr_backend_get_session() will be
removed in the next commit.
This is a re-implementation of wl_shm. The motivations for using
this over the one shipped in libwayland are:
- Properly handle SIGBUS when accessing a wl_buffer's underlying
data after the wl_buffer protocol object has been destroyed.
With the current code, we just crash if the client does that
and then shrinks the backing file.
- No need to fight the wl_shm_buffer API anymore. This was awkward
because we weren't notified when clients created a wl_shm buffer,
and this doesn't play well with our wlr_buffer abstraction.
- Access to the underlying FD. This makes it possible to forward
the wl_shm buffer to a parent compositor with the Wayland/X11
backends.
- Better stride checks. We can use our format table to ensure that
the stride is consistent with the bpp and width.
We'll use this function from wlr_shm too.
Add some assertions, use int32_t (since the wire protocol uses that,
and we don't want to use 16-bit integers on exotic systems) and
switch the stride check to be overflow-safe.
Call glGetGraphicsResetStatusKHR in wlr_renderer_begin to figure
out when a GPU reset occurs. Destroy the renderer when this
happens (the OpenGL context is defunct).
The concept of a persistent accumulated surface offset is wrong
from a protocol point-of-view. wl_surface.offset is tied to a
commit, its interpretation depends on the surface role.
For example, with the following sequence:
wl_surface@1.offset(1, 1)
wl_surface@1.commit()
wl_pointer@2.set_cursor(wl_surface@1, 42, 42)
The final cursor hotspot is (42, 42): the commit which happened
before the set_cursor request has no impact on the hotspot
computation.
The wlr_output_cursor logic already uses wlr_surface.current.{dx,dy}.
wlr_scene's drag icon doesn't, update it accordingly.
Allow to get whether has alpha channel of the VkImage, it can help an
optimization to disable blending when the texture doesn't have alpha.
Because the VkFormat isn't enough because it's always set to
VK_FORMAT_B8G8R8A8_SRGB or VK_FORMAT_R8G8B8A8_SRGB.
This allows compositors to indicate which features they support,
and is required to eventually make this API stable.
References: https://github.com/swaywm/sway/issues/7260
32daa43a45 has removed the asymmetry in
the relationship of a wlr_surface and an unmapped wlr_xwayland_surface,
when wlr_surface.role_data wasn't NULL but wlr_xwayland_surface.surface
was. However, this also means that
wlr_xwayland_surface_from_wlr_surface() now returns NULL if the
wlr_surface is unmapped. Fix the documentation to reflect this.
Before re-using a VkCommandBuffer, we need to wait for its
operations to complete. Right now we unconditionally wait for
rendering to complete in vulkan_end(), however we have plans to
fix this [1]. To fully avoid blocking, we need to handle multiple
command buffers in flight at the same time (e.g. for multi-output,
or for rendering followed by texture uploads).
Implement a pool of command buffers. When we need to render, we
pick a command buffer from the pool which has completed its
operations. If we don't find one, try to allocate a new command
buffer. If we don't have slots in the pool anymore, block like we
did before.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3574
Up until now we were using a VkFence for GPU-to-CPU
synchronization. This has some limitations that become a blocker
when trying to have multiple command buffers in flight at once
(e.g. for multi-output). It's desirable to implement a command
buffer pool [1], but VkFence cannot be used to track command buffer
completion for individual subpasses.
Let's just switch to timeline semaphores [2], which fix this issue,
make synchronization a lot more ergonomic and are a core Vulkan 1.2
feature.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3802
[2]: https://www.khronos.org/blog/vulkan-timeline-semaphores
