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>

protocol/wayland.xml

@@ -305,9 +305,6 @@
 	The drm format codes match the macros defined in drm_fourcc.h, except
 	argb8888 and xrgb8888. The formats actually supported by the compositor
 	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>
       <!-- Note to protocol writers: don't update this list manually, instead
 	   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
       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
       factory interfaces, the wl_buffer interface is frozen at version 1.
     </description>
@@ -1526,6 +1517,13 @@
 	maximise compatibility should not destroy pending buffers and should
 	ensure that they explicitly remove content from surfaces, even after
 	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>
       <arg name="buffer" type="object" interface="wl_buffer" allow-null="true"
 	   summary="buffer of surface contents"/>