On Fri, 28 Feb 2003 22:13:22 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote:
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc based on the feedback I received. As Brian suggested I want to implement the functionality for acquiring available configuration options in libGL. I had a look at xc/lib/GL/dri and it looks as if dri_glx.[ch] would be the right place. Is that correct?
Actually, you should probably look in xc/lib/GL/glx/glxcmd.c. I would add a new function that returns the options. Programs would get a pointer to this function via glXGetProcAddress. You'd have to add the function to the table in glxcmd.c.
The stuff in xc/lib/GL/dri gets compiled into the client-side driver. The stuff in xc/lib/GL/glx gets compiled into libGL.so.
This cannot be quite correct. In xc/lib/GL/dri/dri_glx.c OpenDriver is implemented which loads the client side driver.
I've been tempted to move that file into the GL/glx/ directory. It gets linked with the rest of the files in that directory.
So this must get linked into libGL.so. As part of the code for acquiring configuration information would be very similar to OpenDriver, I thought it would make sense to implement it in the same file.
Sounds good. It can always be moved if necessary.
How would the new functions be exported to client applications? They are obviously not declared in any standard header files. An interested client would also have to do some version checking in order to test whether the new functions are really available. And it would have to check if libGL is from DRI in the first place. How would all this work?
Programs would know whether or not the function exists by the return value of glXGetProcAddress. If it returns NULL, it ain't there. :)
I followed Brians advice and read the glXGetProcAddressARB extension specification, and while I was at it I also took a glance at the GLX spec. So now I understand how an application can find out whether the configuration stuff is available. But glXGetProcAddressARB is a GLX extension itself and the app has to check whether it's available.
I don't know of any libGL on Linux, etc. that hasn't had glXGetProcAddressARB for years now. You'd have a real chicken/egg problem without it. I think you can safely assume its presence.
It would probably use glXGetClientString for that. Now here's the catch: glXGetClientString expects a Display argument. This means the whole configuration query mechanism would only work with an X connection. However, it would be useful if an application could use libGL to get the config info for a specific driver even without an X connection.
Would it be legal to call glXGetClientString with NULL as dpy pointer?
No.
Or did I miss another way of checking for GLX extensions?
GLX_ARB_get_proc_address is special in that you can call it before creating a context, or have a display connection. I don't know of any other GLX extensions like that.
-Brian
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
