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.
The following situation can be dangerous:
- Output DP-1 is plugged in, compositor enables it.
- User VT switches away.
- User unplugs DP-1.
- User VT switches back.
- scan_drm_connectors() figures out the output is now disconnected,
uninitializes the struct wlr_output.
- The loop restoring previous output state in handle_session_active()
accesses the struct wlr_output to figure out what to restore.
By chance, we zero out the struct wlr_output after uninitializing it,
so enabled and current_mode will always be zero. But let's make sure
we handle this case explicitly, to remind future readers that it exists
and make the code less fragile.
`modifiers` and `external_only` are never initialized, and free'd later. This
commit explicitly initializes them to NULL to prevent segfaults on `free()`
It's not safe to destroy any resources which might still be in-use
by the GPU. Wait for any asynchronous tasks to complete before
destroying everything.
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
If NULL is returned by vkGetDeviceProcAddr(), either the driver
is buggy, either the wlroots code is buggy. For a valid device and
command name, drivers are not allowed to return NULL per the spec.
This mirrors what the GLES2 renderer does in load_gl_proc().
