On Tue, Mar 25, 2003 at 09:48:21PM +0000, Keith Whitwell wrote:
....
Utah did have some stuff going for it. It was designed as a server-side-only accelerated indirect renderer. My "innovation" was to figure out that the client could pretty easily play a few linker tricks & load that server module with dlopen(), and then with minimal communication with the server, do 90% of the direct rendering tasks itself. (This was after my first encounter with PI, I think, until then I hadn't heard of direct rendering).
Turns out that most of those dlopen hacks arent neccessary, if you use libglx.so, instead of libglx.a, it seems. ld.so takes care of things automatically, when the X server itself does dlopen() on the extension module.
I'm pretty sure we were using a .so file. The hacks I was talking about related to providing stubs for all the unresloved dependencies, and some layer of indirection that I've forgotten about the justification for.
A "direct rendering" client will still need to do interesting things. But for server-side rendering, the dlopen() stuff does not appear to be neccessary. (At least against xfree4. Maybe it was neccessary with xfree3)
It also turns out that there was a lot of grungy scrninfoP->driverPrivate dereferencing going on, that is also completely unneccessary. So the current Utah-GLX X server interfacing code is a good deal cleaner than when you last looked at it. Many of the old dlopen tricks are still in place; however, new code seems to be directly accessing the server functions with no "tricks".
I'll take your word for it.
Keith
------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
