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
Some opaque pixel formats (nv12, p010) require per-plane bytes_per_block
info. However, it doesn't make sense to store them in
wlr_pixel_format_info, as they will never be useful (currently, this
info is used for shm, which doesn't have a concept of multi-planar
buffers.)
Let's define a separate array and function for determining whether a
pixel format has alpha.
wlr_buffer.c is difficult to read because it contains a mixed bag
of unrelated things: base buffer type, buffer implementations,
buffer resource factory, and client buffer.
Split each of these into their own file.
