[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: Xgl/Xegl future?
From:       Eric Anholt <eta () lclark ! edu>
Date:       2005-08-24 16:55:07
Message-ID: 1124902507.91625.6.camel () leguin
[Download RAW message or body]


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.

-- 
Eric Anholt                                     eta@lclark.edu
http://people.freebsd.org/~anholt/              anholt@FreeBSD.org

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]