Xgl/Xegl future?

Brian Paul brian.paul at tungstengraphics.com
Wed Aug 24 09:59:28 PDT 2005

Eric Anholt wrote:
> On Wed, 2005-08-24 at 17:49 +0200, Matthias Hopf wrote:
>>On Aug 22, 05 14:56:12 -0400, Michel Dänzer wrote:
>>>On Mon, 2005-08-22 at 19:23 +0200, Matthias Hopf wrote:
>>>>On Aug 22, 05 01:01:37 -0400, Michel Dänzer wrote:
>>>>>On Sun, 2005-08-21 at 21:08 -0400, Owen Taylor wrote:
>>>>>>In order to do a good job with a GL-based compositing manager you need:
>>>>>> - Redirection of OpenGL and Xvideo clients
>>>>>This is true whether the compositing manager is GL based or not.
>>>>But an OpenGL based Xserver can use the graphics hardware for scaling
>>>>and color conversion of XV surfaces (that's what I've been working on).
>>>So can a GL based compositing manager.
>>No. Not with current Xservers. No way to get YUV / YUY2 data in native
>>format. This isn't easily possible to implement, either, as the PutImage
>>call does not have to completely fill a Window, and RGB data can be
>>drawn over it afterwards as well.
> Obviously a GL compositing manager wouldn't be doing the YUV to RGB
> conversion, since the compositing manager is at the wrong level.  It
> should be done in the XV handler of the driver in the DDX.  It's been
> done in several KAA (aka EXA) drivers before, using the graphics
> hardware for scaling.
> GL isn't needed to do this.

Just FYI, there's the GL_MESA_ycbcr_texture extension that let's you 
pass a YCbCr texture image to GL.  The YCbCr -> RGB conversion is done 
by the hardware when the texture is applied to a polygon.

Arbitrary color-space conversion can also be done with fragment 
programs nowadays.

Using the GL hardware for that kind of stuff seems pretty interesting.


More information about the xorg mailing list