Converting the LCMS2 transform to a 3D LUT early causes issues:
- It's a lossy process, the consumer will not be able to pick a
3D LUT size on their own.
- It requires unnecessary conversions and allocations: an intermediate
3D LUT is allocated, but the renderer already allocates one.
- It makes it harder to support arbitrary color transforms in the
renderer, because each type needs to be handled differently.
Instead, expose a function to evaluate a color transform, and use
that to build the 3D LUT in the renderer.
The old approach of using a signal is fundamentally broken for a common
usecase: When the waiter is ready, it's common to immediately finish and
free any resources associated with it.
Because of the semantics of wl_signal_emit_mutable() this is UB.
wl_signal_emit_mutable() always excepts that the waiter hasn't been freed
until the signal has finished being emitted.
Instead of over engineering the solution, let's just add a callback required
by wlr_drm_syncobj_timeline_waiter_init(). In this callback, the implementation
is free to finish() or free() any resource it likes.
It makes sense to use udmabuf when the backend wants shm, the
renderer wants DMA-BUFs, and we don't have a DRM FD because we're
running with a software renderer (e.g. llvmpipe or lavapipe).
udmabuf can create a DMA-BUF backed by a memfd. This is useful
when running with a software implementation of GL/Vulkan: the memfd
can be passed to the parent compositor via wl_shm and the DMA-BUF
can be imported via the usual APIs into GL/Vulkan.
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
Perform a primitive garbage collection of buffers that have not been
used in the past 10 seconds, an arbitrarily selected number.
As garbage collection also makes span buffer allocation happen much more
often, logging on allocation activity leads to a lot of log noise so get
rid of that while at it.
With this change vulkan renderer can be automatically chosen in two more cases:
GLES2 renderer is disabled at compile time
GLES2 renderer failed to be created
Main purpose of this change is to automatically choose vulkan as renderer when GLES2 renderer is not enabled.
