Deep Color support

[Jasper St. Pierre]

Outside of an X11 environment, the only standard is EGL, with a Wayland
backend for Wayland apps, or a GBM backend for native modesetting. I don't
know whether the Intel drivers have support for 64-bit textures on either
of these backends. Writing a little test app is probably the easiest way to
finding out.

FBConfigs are separate, but they're generic enough where you can just
iterate through the list of FBConfigs on Wayland / GBM and see if you get a
16-bit visual there. I can't imagine you would, though.


On Sat, Apr 26, 2014 at 5:02 PM, Wolfgang Draxinger <
wdraxinger.maillist at draxit.de> wrote:

> 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
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140426/b397684c/attachment.html>