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
Added wlr_vk_renderer_get_* functions to allow get the VkInstance,
VkPhysicalDevice, VkDevice, queue family of a wlr_vk_renderer.
Added wlr_vk_renderer_get_current_image_attribs function to allow get
the VkImage of current renderer buffer to use on compositors.
Added wlr_renderer_is_vk function, it's like the wlr_renderer_is_gles2,
returns true if the wlr_renderer is a wlr_vk_renderer.
Added wlr_vk_image_get_attribs function to get a VkImage and it's
extras information (e.g. a VkImageLayout and VkImageFormat of the
VkImage) from a wlr_texture.
In wlroots we add comments near struct wl_list members to indicate
which type it's linked to. The Vulkan renderer had some comments
with mistakes, and some members without a comment.
Simon Ser
zccrs
Alexander Orzechowski
fakechen
Kirill Primak
illiliti
David96
Isaac Freund