On Thu, 20 Feb 2003 01:49:43 -0600 (CST) "D. Hageman" <[EMAIL PROTECTED]> wrote:
> On Wed, 19 Feb 2003, Brian Paul wrote: > > > Felix Kühling wrote: > > > 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. > > > > Nice work! I think you've covered all the issues I'm aware of. > > Sweet! > > > 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 am not opposed to this idea. I know originally we were planning > on staying away from Mesa if we could just to keep things simple and > hopefully have a faster implementation time. However - anything that we can > do to make it easier and potentially be better for the end user - I > support fully. Felix - see any problems with this? No problems. In fact, libGL has not much to do with Mesa. Mesa is compiled into the *_dri.so drivers. libGL loads the correct driver or works as a GLX protocol encoder if direct rendering is not available. libGL has to know where to find the driver. So why duplicate this information in the configuration tool? > > Thanks for the feedback Brian! Same here! Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ [EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time! ------------------------------------------------------- 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