Deep Color support

[Wolfgang Draxinger]

On Sat, 26 Apr 2014 23:38:32 +0300
Pekka Paalanen <ppaalanen at gmail.com>
wrote:

> 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.
> 
> ...
> 
> 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.

I suspected as much. Do you happen to know how far the support for deep
color is in Mesa and DRM? I know that OS-Mesa has some deep color
support; However OS-Mesa is a softpipe implementation that renders into
a user supplied memory area, which I'm not interested in.

This is going a little bit off topic now, but any Mesa / DRM developer
reading this please chime in:

At least the Intel drivers via GLX/DRI have support for 64 bit
(16 bit per channel) textures that works very well. In combination
with a OpenGL framebuffer object that gives you deep color rendering
capabilities. What I'm now interested in is creating a deep color
main framebuffer outside an X11 environment. In light of a
composited environment such a framebuffer should be off-screen (or
off-scanout) of course.

Which are the relevant API (calls) I'd have to look into for doing
that? And how would those cogs fit together? Unfortunately the
documentation regarding the relevant low level mechanisms is thin to
non-existent; essentially it boils down to reading the source of things
like libgbm and Mesa's EGL backends; and many things are easily
overlooked. I have a very clear high level understanding of how things
fit together, but the devil is in the details.


Regards,

Wolfgang