On Sunday I researched what it would take to migrate the libglx.a-libGLcore.a interface to match the (new) libGL.so-*_dri.so interface. Much to my surprise, I don't think it will be as difficult as I had first thought. There are a few issues.
1. Right now libGLcore has several entry-points for getting GLX visual information into the driver. The file programs/Xserver/GL/mesa/X/xf86glx.c contains all of this interface. The interface functions are __MESA_initVisuals, __MESA_setVisualConfigs, and __MESA_screenProbe. __MESA_screenProbe is analogous to __driCreateNewScreen. The other two functions server part of the purpose of __driCreateNewScreen, but they also do some work not related to the driver. They create a list of X (not GLX) visuals to give back to the X server. That functionality should be moved into libglx.a.
2. Mesa's X11 driver, which is the basis of libGLcore, depends on information from an X VisualInfo. Most of the uses can be eliminated trivially, but the depth / nplanes and ColomapEntries / colormap_size fields are another story. The problem here is that the __driCreateNewScreen doesn't, and can't, provide VIsualInfo structures to the driver.
3. libglx.a calls functions in directly instead of using a dispatch table. Let me clarify this a bit. On the client-side, the symbol glVertex3f is libGL.so. When an app calls that function, it looks up the "real" function and calls it. On the server-side, the symbol glVertex3f is in libGLcore.so (i.e., the driver). When a glVertex3f protocol message comes in, libglx.a calls this function directly. This function then may (or may not, as in the case of the Mac OS X libGLcore.a) do a dispatch table look-up. What should happen is the protocol functions should do the dispatch table look-up and call the function from the table.
Those are the big issues that I could find. The rest of it just looks like changing function parameters and data structures, or moving code from libGLcore to libglx. I've attached a patch that removes some of the dependance on the VisualInfo structure and removes some redundant fields from the mesa_visual structure. Unless there are objections, I will commit this soon. I've only tested this with stand-alone Mesa so far.
------------------------------------------------------------------------
The patch looks good, Ian.
As Keith has mentioned a few times over the years, another approach to unifying libGLcore.a and the *_dri.so drivers would be replace the XMesa stuff with a new DRI pseudo-hardware driver that used software fallbacks for everything. That is, completely remove the XMesa stuff from the picture.
-Brian
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
