Gitlab Markdown will allow us to use math if necessary.

I couldn't find a better way to set up a definition list, but at least
the index lists them now.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

v3:
- Add mention that AMD display pipeline color-processing block's impact
  on power are negligible in comparison to memory bandwidth and GPU
  power (Sebastian)

v2:
- Add link to README.md (Pekka)
- Make it clear that compositors don't currently do color space conversions.
  Applications will perform their own color space conversion when required,
  such as when playing back HDR videos. (Sebastian)
- Avoid some generalizations about color-managed compositor behavior while
  highlighting that a color-managed compositor will likely have a larger GPU
  and memory bandwidth usage (Pekka)
- Clarify the importance of 3D LUT for high-quality tone-, and gamut-mapping
  (Sebastian)
- Soften language of power-saving implications of RGB 10bpc scanout instead of
  FP16 scanout (Harry)
- Add blurb on de-linearizing content post-blending when needed (Sebastian)
- Use unambiguous language to refer to the display controller, instead of the
  actual display (Pekka)
- Spell out PWL, and TF acronyms when first introduced (Pekka)
- Clarify the de-linearization and linearization performed on drm_plane and
  drm_crtc respectively for the video use case (Pekka)
Signed-off-by: Harry Wentland <harry.wentland@amd.com>

Signed-off-by: François-Xavier Thomas <fx.thomas@gmail.com>

Add a story on what one would need to know to process and display a
pixel.

This is an introduction to people who are already familiar with computer
graphics in general, images in memory, and maybe window systems, but
never really thought what the values in a pixel actually mean or what
they are doing wrong with them.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Pekka Paalanen authored Oct 20, 2021 and Pekka Paalanen committed Nov 10, 2021

For images, it's nice to have also the sources in case someone needs to
edit the image later.

For math, these hints should help typesetting math with less pain.

Thanks to @mstoeckl

 for the KaTeX demo link.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

The only thing left in color.rst are the misc notes. Rename the file
accordingly.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

No changes to content. This finishes the color.rst splitting.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

That chapter considers HDR from the Wayland and window system
perspective, and it is quite WIP.

No changes to the content.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Tables of well-known EOTFs, chromaticities and whitepoints moved into a
file of their own, without changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

This continues splitting up color.rst.

No changes to the content.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

color.rst is a little long already, and we wish to get more
documentation that may be hard to integrate in color.rst (making it even
longer, not quite fitting with the topic, or needing features like math
markup). Therefore start splitting it up and collect a ToC straight in
the README.

This patch moves the design goals as-is into a new file. The design
goals are considered mature and unlikely to change, unlike some other
parts.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Pekka Paalanen authored Sep 27, 2021 and Pekka Paalanen committed Sep 28, 2021

Set up the usual project rules, following what wayland-protocols and
wayland use.

Granting permissions is eased given this is mostly for documentation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>