mirror of
https://gitlab.freedesktop.org/wayland/wayland-protocols.git
synced 2025-12-24 16:00:10 +01:00
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:
parent
ce96b5f177
commit
5215432aaa
1 changed files with 5 additions and 4 deletions
|
|
@ -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"/>
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue