Disable xterm and XRX builds per default / [Fwd: CVS Update: xc (branch: trunk)]
Ian Romanick
idr at us.ibm.com
Tue Jan 25 08:07:34 PST 2005
Alexander Gottwald wrote:
> On Mon, 24 Jan 2005, Ian Romanick wrote:
>
>>The net result is that the Darwin and Cygwin builds will need a "fake"
>>DRI driver that creates this dispatch table. One nice side-effect of
>>that is that it will remove the platform-dependent stuff (e.g., work
>>around GL functions missing in some versions of OS X) from libglx.
>
> The dispatch table is a mapping GLX call -> OpenGL function? Something
> that is done in g_disptab.c now?
On the server there is a mapping from GLX protocol opcode to GL
function. This is done by g_disptab.c and friends. Right now this
calls the GL function by name. In the current setup, the GL function
"names" live in libGLcore. Within libGLcore (at least for the Mesa
software version), there is a pointer to a dispatch table for the
currently bound context. The GL functions end up looking something like:
void glBegin( GLenum mode )
{
dispatch->Begin( mode );
}
They aren't exactly like that, but it's close enough for this discussion.
I'm proposing that the pointer (i.e., dispatch) live in libglx instead
of libGLcore and that the gl* functions be removed altogether. This
matches the way libGL.so / *_dri.so work on the client-side. At context
creation time libGLcore be able to modify the dispatch table functions
to point to whatever it needs. This could be to functions in Mesa, the
Apple OpenGL library, or opengl32.dll. In either case it happens in
libGLcore and *not* in libglx.
The code that currently lives in the gl* functions would just get folded
into the __glXDisp_* functions. In that way the __glXDisp_* functions
in libglx become like the gl* functions in libGL.so. If we look at
libglx / libGLcore as a driver loader and a driver, this makes good sense.
This also moves all of the platform dependent stuff out of libglx. All
of the quirky stuff in libglx for determining what GL functions are
supported on Darwin, for example, moves to libGLcore. In fact, instead
of happening at compile time, it could be done at run-time. The same
could be done for Cygwin. You had mentioned that Cygwin could either
use Mesa or opengl32.dll. I assume that this selection is made at
compile time. Moving forward, this could be done at run-time by loading
either a Mesa version of libGLcore or an opengl32.dll version.
Ultimately, the name libGLcore will go away, and it would be either
mesasw_dri.so or opengl32_dri.so on Cygwin.
My intention is to get this working on Linux first, then worry about
getting it working on the other platforms. And like I said before, this
is still a long way from seeing fruit.
More information about the xorg
mailing list