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
