mirror of
https://gitlab.freedesktop.org/wlroots/wlroots.git
synced 2026-02-11 04:28:02 -05:00
30ccac3a02
A footgun in the wlr_buffer API is that there's no difference between acquiring a buffer and increasing the lock count. In other words, transitioning a buffer from the released state to the acquired state is not explicit. This may result in hard-to-debug failures if there is a dangling released wlr_buffer somewhere (e.g. wlr_client_buffer.source [1]) and some piece of code calls wlr_buffer_lock(). In that case, the buffer will be acquired and released again. In the context of a wlr_buffer issued from a Wayland protocol wl_buffer object, this can cause the underlying memory to be used after wl_buffer.release has been sent to the client, and a double wl_buffer.release event to be sent. Make it so acquiring a buffer is an explicit operation to make sure the caller means the state transition and is prepared for a new release event. wlr_buffer_acquire() forbids calls on already-acquired buffers, and wlr_buffer_lock() now forbids calls on released buffers. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4904 |
||
|---|---|---|
| .. | ||
| allocator | ||
| gles2 | ||
| pixman | ||
| vulkan | ||
| color.c | ||
| color_fallback.c | ||
| color_lcms2.c | ||
| dmabuf.c | ||
| dmabuf_fallback.c | ||
| dmabuf_linux.c | ||
| drm_format_set.c | ||
| drm_syncobj.c | ||
| egl.c | ||
| meson.build | ||
| pass.c | ||
| pixel_format.c | ||
| swapchain.c | ||
| wlr_renderer.c | ||
| wlr_texture.c | ||