>> I have no idea where to start though to do that myself. Any help
>> on doing this would be greatly appreciated.
>
>
>I think we've been over this before but let's see I've got the whole
>picture.
First time I've encountered it, I think the topic has likely come
up before, but it was not with me if so...
>The core problem is that you need a different libGL.so depending on
>whether XFree86 3.3.6 or 4.x is being run, right?
>
>Both 3.3.6 and 4.x might be installed at the same time as well, right?
>
>If you're running 4.x then you'll always get the GLX server extension
>regardless of the hardware installed. And hence, OpenGL capability.
Right.
>With 3.3.6 there isn't a GLX server extension so OpenGL capability is
>provided by "stand-alone" Mesa, which is version of libGL.so which
>effectively converts GL calls into Xlib protocol which renders on any
>X display.
Yep.
>Another scenario is someone using the XFree86 4.x libGL.so who wants
>to remote-display to an XFree86 3.3.6 server. libGL.so will look for
>the GLX extension on the 3.3.6 server, not find it, and die. In this
>case you'd like to have libGL.so fallback to "stand-alone" mode and
>generate Xlib protocol.
Correct.
>Previously, you made a hybrid libGL.so that was both GLX/DRI-aware
>and could also fallback to stand-alone/Xlib mode. Is that no longer
>working? I seem to recall hearing of some problems with it.
It wasn't me that did that, I believe Bill Nottingham did the
work initially, then Bernhard Rosenkranzer maintained it until
recently, and I now have our Mesa package, and planning on
integrating it directly into our XFree86 RPM, as it would solve
some problems with packaging, etc.
>I remember getting a patch for this hybrid libGL long ago but never
>incorporated it because I was too busy and not 100% sure it was the
>right thing to do. Maybe I should revisit this if it'll help.
It would indeed help I believe. I know of no problems with our
solution anyway as far as the end user is concerned - which
doesn't of course mean that there aren't any either.. There
haven't been any bugs reported pertaining to it to my knowledge
anyway. The big downside is more that of package maintenance
than anything.
Thanks,
TTYL
----------------------------------------------------------------------
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc. Ontario, Canada, P6C 5B3
http://www.redhat.com Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS: ftp://people.redhat.com/mharris/testing
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
