[patches] Add a color management framework to weston

[Bill Spitzak]

How is this intended to work in Wayland?

Are clients supposed to tell the compositor what color space their 
buffer is, and the compositor then converts to the output's color space 
as part of the compositing step? Problems with this:

  * We need a reliable way for clients to tell compositor what color 
space they are rendering, ideally without huge amounts of code such as 
the same color space converter library in the client.
  * Fast conversion of an 8-bit buffer between color spaces reduces the 
effective number of bits of color to 7 or even 6, and can introduce ugly 
artifacts. Adding enough noise (what most shaders call dithering) can 
hide this but obviously adds noise. Computing the output color space at 
higher accuracy and then doing proper error diffusion dithering is 
better, but slow on many GPUs. Requiring the buffers to be higher than 
8-bit precision can fix this but people may question Wayland's 
commitment to allowing efficient clients.
  * Is "same as the output" a supported color space?

Or are clients supposed to get the color space needed and convert to it 
when rendering their buffers? This seems more Wayland-like but has problems:

  * problem if the surface is on more than one output
  * multiple copies of the color-correction library and loaded color 
space descriptions in each client
  * need for message from compositor to client to change the color 
space, and compositor must wait for commit from all clients before 
updating the screen.
  * Clients may not have access to the color correction hardware that 
the compositor has.

Richard Hughes wrote:
> I've attached three patches for comments and review. I'm a GLib
> programmer at heart, so please be kind if I've made huge obvious
> architectural mistakes :)