Xgl in X.org tree

[Dave Airlie]

> >
> > The fb/render changes (from davidr) are mainly support for YUV and
> > Picture types, these should be safe to be put into the main tree
> > provided they are reviewed a bit better, I'm betting the current code
> > on the branch is incorrect with some of the repeat stuff, as this was
> > different between xserver and xorg for backwards compat reasons.. I'm
> > also not sure if anything in there might be an ABI buster.
>
> The YUV picture code needs a second look. The repeat stuff should be
> correct. Repeat, Pad, Reflect should now be working correct with
> gradient and normal pictures.

The only problem was
http://cvs.freedesktop.org/xorg/xserver/xorg/render/picturestr.h?r1=1.14&r2=1.15
an ABI compat change, it named things a bit differently than xserver
from what I can see and I'm not sure I got them all correct on the way
over..

>
> Lars Knoll who wrote the initial gradient code probably wants to have a
> look at the gradient updates before they land in the main tree. E.g.
> I've temporarily disabled the use of color tables until we have some
> code to figure out when they can be used without loss of quality and
> when not.
>
> >
> > The GL changes need a bit of work, the MESA_render_texture code is the
> > bulk of them and we aren't going to use that going forward, so it
> > won't make it back into CVS HEAD, the other changes have some hacks to
> > make things work on Xgl but that break the X.org tree, I'm also not so
> > happy about the malloc/free function duplication I ended up doing
> > between glx and glcore, I'm not 100% sure how this stuff will interact
> > with krh's work on aiglx....
> >
> > There is also a current patch against Mesa stable at
> > http://people.freedesktop.org/~airlied/xgl/
> > It is against the Mesa 6.4 stable branch. and is required to compile
> > Xgl for mangling fixes and to get glxcompmgr going.
>
> You shouldn't have to use the mangled namespace with Xgl any longer.

You'd think that but you'd be wrong :-) (but I may be missing
something), when running with dispatch tables, the dispatch table
pointer is called _glapi_Dispatch also functions
called_glapi_set_dispatch and _glapi_get_dispatch, however this symbol
is also provided by libGL (in the DRI case) and used by the lowlevel
hw DRI driver so it has to be global, we do not want to touch this
symbol, however I found xgl/glx/glcore code using the global copy from
libGL and not the one we wanted them to use, switching it to
_mglapi_Dispatch seems to avoid this issue and make it all work, I'm
open to suggestions on how this might be avoided,

Dave,