Deep Color support

[Pekka Paalanen]

On Sat, 26 Apr 2014 21:15:33 +0200
Wolfgang Draxinger <wdraxinger.maillist at draxit.de> wrote:

> Hi,
> 
> could someone please fill me in, if and if yes, how deep color
> modes (more than 8 bits per color channel) are (going to be)
> supported and handled by the Wayland protocol, compositors and
> clients?
> 
> I'm currently toying around (for self educational purposes) with
> direct access to the GPU (using libgbm, libdrm and EGL). But I've
> found only very little information on how deep color modes can be
> implemented. I understand that most available display scanouts
> don't support it (hardware wise), but for framebuffer contents
> exchanged between processes and for color management deep color
> is essential.
> 
> Anyway, with libgbm I was able to successfully create a
> X2R10G10B10 mode on the display scanout. However I'm also
> interested in really deep modes like A16R16G16B16.
> 
> So how are those things handled by Wayland?

Hi,

well, as far as Wayland is concerned, the color depth is only a
pixel format, which is an arbitrary enumeration. For example, you
can see the declared pixel formats for wl_shm type buffers in
http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n279
and more can be easily added.

Buffer types that support hardware acceleration of rendering and/or
compositing have their own pixel format lists, e.g.
http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland/wayland-drm/wayland-drm.xml#n39
for Mesa EGL.

But the "hard" part is to get compositors to advertise new formats,
and clients to take advantage of them. Wayland itself is the easy
part.

If you want, you could easily define your own buffer factory
similar to wl_shm, that supported, say, FP64 channels
in hyperspectral colors. The protocol is easy, the real work is in
making it actually useful.

Your question would probably be more interesting if you asked how
deep colors can be supported by kernel DRM, GBM implementations,
Mesa, or whatever will be used for rendering or compositing. Those
are where the limitations are, not Wayland. In the end, Wayland
only deals with handles to buffers, not pixels as such.


Thanks,
pq