My approach in libGL was to make a single "master" routine that glXMakeCurrent, glXMakeContextCurrent, and glXMakeCurrentReadSGI all call. The greatly simplified the code. I would like to duplicate that model on the server-side. My biggest uncertainty is where the API boundries are (i.e., where the binary compatability problems are). I believe that it is safe for me to modify the __GLXcontextRec (in programs/Xserver/GL/glx/glxcontext.h). I need to replace pGlxPixmap & glxPriv with separate read & draw pointers. I have also modified __glXMakeCurrent (in programs/Xserver/GL/glx/glxcmds.c) to be a new function called DoMakeCurrent that takes a client state pointer, read & draw drawable pointers, a context ID, and a context tag and "does the right thing." Things are pretty smooth up to this point.
The problem comes in gc->exports.makeCurrent (called by __glXMakeCurrent in the original code). As near as I can tell, this is set to __MESA_makeCurrent (located in programs/Xserver/GL/mesa/src/X/xf86glx.c, line 775). This function makes an "imported" call to get the current drawable and calls XMesaMakeCurrent. Herein lies the problem. I need to add a new imported called (something like getReadablePrivate) and change __MESA_makeCurrent to call XMesaMakeCurrent2.
Just by looking at how things are called, making these changes would seem to be a binary compatability problem. Is that assessment correct? It seems like I can, with a certain amount of pain and suffering, work around the problem *if* I can detect when the different binaries are expecting different interfaces. Does anyone have any advice on how to do that? Is there any way for libglx.a and libGLcore.a to tell which version the other is? Is it safe to expect that both will always be in sync?
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel