Felix Kühling wrote:
Nice work! I think you've covered all the issues I'm aware of.Hello list,D. Hageman and I have been bouncing a design document for the new configuration infrastructure back and forth in private mail for the past week. Now we think it's ready for public discussion. You may notice that the structure is quite similar to Ians texmem design. This is the first time I'm writing such a document so I took Ian's work as a good example. The document is attached in plain text format.
I have one idea to bring up though. As it is now, you have a 'driConfigurationOptions' symbol in each *_dri.so driver file which would be accessed via dlopen/dlsym. It's up to the configuration tool to determine which driver file to open for a particular screen (using the XF86DRI extension).
What if libGL did that for you? That is, we'd add a new internal function to libGL like this:
const char *libglGetConfiguratinOptions(Display *dpy, int screen);
So, you'd use dlopen() to open libGL.so", then call that function for whichever display/screen you're interested in. libglGetConfiguratinOptions(), in turn, would dlopen the appropriate DRI driver and fetch the options associated with 'driConfigurationOptions'.
Then, we'd actually have a DRI-independant mechanism that could potentially be picked up by NVIDIA and ATI for their binary drivers. All they'd have to do is implement the libglGetConfiguratinOptions() function in their libGL.so libs.
I think that would be a good thing for the end users.
-Brian
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
