staging/color-representation: set_chroma_location vs. pixel format

There is no value in chroma_location enum that would be compatible with
any RGB-like or some of the YCbCr pixel formats. Hence, the chroma
location can be compatible with those pixel formats only if chroma
location has never been set, or the wp_color_representation_surface_v1
object is destroyed. While this would technically work, it seems
cumbersome, and different from set_coefficients_and_range.

Choosing the lesser change, this patch proposes to just ignore chroma
location if it does not apply to the pixel format.

The alternative would be to add a "unset" value to the chroma location
enum, requiring an interface version bump.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This commit is contained in:
Pekka Paalanen 2025-11-20 14:17:25 +02:00
parent ce96b5f177
commit 5215432aaa

View file

@ -417,14 +417,15 @@
An invalid chroma location enum value raises the "chroma_location"
protocol error.
A call to wl_surface.commit verifies that the pixel format and chroma
location type in the committed surface contents are compatible, if
contents exist. The "pixel_format" protocol error is raised otherwise.
For the definition of the supported chroma location types, see the
wp_color_representation_surface_v1::chroma_location enum.
The chroma location type is double-buffered, see wl_surface.commit.
If the pixel format is not 4:2:0 sub-sampled at the time
of wl_surface.commit, the chroma location is not used for rendering
the surface until a 4:2:0 sub-sampled pixel format is committed on
the surface.
</description>
<arg name="chroma_location" type="uint" enum="chroma_location"
summary="chroma sample location"/>