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

List:       freedesktop-xorg
Subject:    Re: Xgl/Xegl future?
From:       Michel =?ISO-8859-1?Q?D=E4nzer?= <michel () daenzer ! net>
Date:       2005-08-26 3:05:04
Message-ID: 1125025504.4364.284.camel () localhost
[Download RAW message or body]

On Thu, 2005-08-25 at 18:30 +0200, Matthias Hopf wrote:
> On Aug 24, 05 10:59:28 -0600, Brian Paul wrote:
> > >>>>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.
> 
> Yes, but as soon as we want an abstraction layer (in this case OpenGL),
> this isn't easily accessible, as several hardware vendors chose to not
> convert YUV to RGB on PutImage, but during scanout (using color keying
> for selecting the YUV framebuffer).

We're not talking about overlays (which will be little use with
compositing) but about using the 3D engine to do the colourspace
conversion and scaling.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

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