From: Brian P. <br...@tu...> - 2003-03-03 03:28:49
|
Felix K=FChling wrote: > On Fri, 28 Feb 2003 22:13:22 -0800 > Ian Romanick <id...@us...> wrote: >=20 >=20 >>Felix K=FChling wrote: >> >>>Hello, >>> >>>I just started working on a revision of the DRI Configuration design d= oc >>>based on the feedback I received. As Brian suggested I want to impleme= nt >>>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=20 >>add a new function that returns the options. Programs would get a=20 >>pointer to this function via glXGetProcAddress. You'd have to add the=20 >>function to the table in glxcmd.c. >> >>The stuff in xc/lib/GL/dri gets compiled into the client-side driver.=20 >>The stuff in xc/lib/GL/glx gets compiled into libGL.so. >=20 >=20 > 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=20 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 mak= e > 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 a= re >>>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=20 >>value of glXGetProcAddress. If it returns NULL, it ain't there. :) >=20 >=20 > 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 glXGetProcAddres= sARB=20 for years now. You'd have a real chicken/egg problem without it. I thin= k you=20 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 th= e > config info for a specific driver even without an X connection. >=20 > 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 creati= ng a=20 context, or have a display connection. I don't know of any other GLX=20 extensions like that. -Brian |