In query_modifier_support, the calloc for either or both of render_mods
and texture_mods may fail, in which case both are freed for convenience.
However, if one is non-NULL, vulkan_format_props_finish will try to free
it again.
NULL them to avoid double-free.
Stop trying to maintain a per-file _POSIX_C_SOURCE. Instead,
require POSIX.1-2008 globally. A lot of core source files depend
on that already.
Some care must be taken on a few select files where we need a bit
more than POSIX. Some files need XSI extensions (_XOPEN_SOURCE) and
some files need BSD extensions (_DEFAULT_SOURCE). In both cases,
these feature test macros imply _POSIX_C_SOURCE. Make sure to not
define both these macros and _POSIX_C_SOURCE explicitly to avoid
POSIX requirement conflicts (e.g. _POSIX_C_SOURCE says POSIX.1-2001
but _XOPEN_SOURCE says POSIX.1-2008).
Additionally, there is one special case in render/vulkan/vulkan.c.
That file needs major()/minor(), and these are system-specific.
On FreeBSD, _POSIX_C_SOURCE hides system-specific symbols so we need
to make sure it's not defined for this file. On Linux, we can
explicitly include <sys/sysmacros.h> and ensure that apart from
symbols defined there the file only uses POSIX toys.
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.
This is the last of a set of commits which ensures that both textures
and render buffers can be accessed through _UNORM and _SRGB image
views. While _UNORM image views are not yet used for 8-bpc image
formats, they will be needed in the future to support color transforms
for both textures and render buffers.
Sadly, the new API is not backwards compatible with the old API. Since
we have already switched all users in wlroots to the new API compositors
are already practically mandated to implement the new API. Let's get rid
of the old one since there is no point.
When a texel from the Vulkan format VK_FORMAT_B8G8R8A8_SRGB is read,
the sRGB to linear conversion is applied independently to the R, G,
and B channels; the A channel has no influence on this. However,
DRM_FORMAT_ARGB8888 buffers are, per Wayland protocol, not encoded
in this fashion; one must first unpremultiply the color channels
before doing sRGB to linear conversion. This commit switches to
handling ARGB8888 and ABGR8888 formats using the general fragment
shader conversion from electrical to optical values.
If the compositor were to try to handle a GPU reset within the lost
signal (by recreating the renderer) we should avoid referencing renderer
resources after the lost signal. This prevents use after free for such
compositors.
This will become necessary when we switch away from scissoring. For the
time being, this cleans things up a bit and allows for a trivial
blending implementation for textures when that comes.
Avoids repeating the common bits between dma_tex_features and
dma_tex_ycbcr_features, and we will need just the YCbCr-related
flags for shm YCbCr support soon.
These features are required for shm only: the TRANSFER stuff is
for texture upload. We don't need these for DMA-BUFs. Make this
clearer by changing the name.
Also re-order the definitions to group all texture-related features
together.
