protocol: move wl_buffer interpretation to wl_surface.attach

A wl_buffer is always a dumb collection of color channels whose
interpretation is determined ad-hoc at the point of use. For example, is
is possible for the same buffer to be attached two wl_surfaces
concurrently:

- The first surface interprets the color channels as sRGB with
  pre-multiplied alpha.
- The second surface interprets the color channels as BT.2020/PQ with
  straight alpha.

Therefore the interpretation is not a property of the wl_buffer itself.
Factory interfaces for wl_buffer object should therefore only talk about
how the electrical values are communicated between clients and
compositors.

Signed-off-by: Julian Orth <ju.orth@gmail.com>
This commit is contained in:
Julian Orth 2025-06-03 12:40:00 +02:00
parent 6281ccbd3d
commit 4ed26b057e

View file

@ -305,9 +305,6 @@
The drm format codes match the macros defined in drm_fourcc.h, except The drm format codes match the macros defined in drm_fourcc.h, except
argb8888 and xrgb8888. The formats actually supported by the compositor argb8888 and xrgb8888. The formats actually supported by the compositor
will be reported by the format event. will be reported by the format event.
For all wl_shm formats and unless specified in another protocol
extension, pre-multiplied alpha is used for pixel values.
</description> </description>
<!-- Note to protocol writers: don't update this list manually, instead <!-- Note to protocol writers: don't update this list manually, instead
run the automated script that keeps it in sync with drm_fourcc.h. --> run the automated script that keeps it in sync with drm_fourcc.h. -->
@ -479,12 +476,6 @@
client provides and updates the contents is defined by the buffer factory client provides and updates the contents is defined by the buffer factory
interface. interface.
Color channels are assumed to be electrical rather than optical (in other
words, encoded with a transfer function) unless otherwise specified. If
the buffer uses a format that has an alpha channel, the alpha channel is
assumed to be premultiplied into the electrical color channel values
(after transfer function encoding) unless otherwise specified.
Note, because wl_buffer objects are created from multiple independent Note, because wl_buffer objects are created from multiple independent
factory interfaces, the wl_buffer interface is frozen at version 1. factory interfaces, the wl_buffer interface is frozen at version 1.
</description> </description>
@ -1526,6 +1517,13 @@
maximise compatibility should not destroy pending buffers and should maximise compatibility should not destroy pending buffers and should
ensure that they explicitly remove content from surfaces, even after ensure that they explicitly remove content from surfaces, even after
destroying buffers. destroying buffers.
Unless specified otherwise by a protocol extension, the compositor
assumes that the values stored in the wl_buffer use pre-multiplied
alpha, are pre-multiplied in electrical values, use an
implementation-defined color space, and use an implementation-defined
transfer function. These color spaces and transfer functions are usually
sRGB, but this depends on the compositor.
</description> </description>
<arg name="buffer" type="object" interface="wl_buffer" allow-null="true" <arg name="buffer" type="object" interface="wl_buffer" allow-null="true"
summary="buffer of surface contents"/> summary="buffer of surface contents"/>