On Sun, Jul 01, 2001 at 03:38:16PM +0200, Marcelo E. Magallon wrote: > > That still doesn't help in terms of something like an OpenGL driver > > which isn't something that a vendor will just provide and expect to > > work. It takes a fair bit of work to get OpenGL set up at the moment > > and you're not going to be able to automate that I suspect. > > that is your experience, please don't make generalizations based on > that alone. No. that is simple fact. If you have a DRI-supported card, you must compile not one, but two custom kernel modules for that card on your machine. These can be made for users if you give them canned kernels usually. Then you must install the necessary libraries and fiddle with an XF86Config-4 by hand, generally speaking. (This if you can get the damned thing to work, which I have had very mixed success with..) Fortunately these days all DRI drivers except tdfx install the same way. Installing tdfx removes one step and adds another, but if you simply add the install libglide3 step you're okay to forget to remove the load agpgart step. If you have a Voodoo2, you have an entirely different set of installation procedures. To add insult to injury, while one set of code works fine for GLX in general, Mesa with a Voodoo2 requires slightly different code. So does the Voodoo3 sometimes, with the added benefit that if you screw it up on the Voodoo3 side, you kill the video card usually resulting in a reboot needed if you're lucky or a hard crash if you're not. Users can't tell if code is "3dfx-safe" or if it's going to behave weirdly till they run the app. Most recently written apps are, fortunately, as long as they were not written for GLUT. I won't even go into NVidia, whose standard installation is likely to hose something if you're not damned careful. > That said, the LSB (see? I can type, I can type!) doesn't specify > glXGetProcAddressARB as a "valid" (sanctioned, whatever) function to > use, which is *bad*. (I think the LSD may turn out to have been more accurate by the time we're all through here...) Reason why they don't is probably because GLX 1.3 is not universally adopted by all parties yet, and is likely to not be deemed so for at least a few months. NVidia claims to have everything for 1.3 except that function in their headers, which is amusing since they do have the function. *sigh* The Efnet #OpenGL FAQ explains how to properly test for the function at run-time. You still have to play with dlopen, but the function is very clean and may only need to do so once. > What some people seem to be missing here is that the LSB says a package > might depend only on the lsb package. Presumably this lsb package > depends on all the stuff that makes the system LSB conformant. On > Debian this is something like xlibs, libc6, xlibmesa3 | libgl1, zlib1g, > libncurses5. The xlibs one might be overkill, the LSB calls for > X11R6.4 and some extensions. I don't recall reading they call for GLX. Have I missed something? In any event, as of this message the discussion has veered completely off the topic of LSB and on to the topic of what a pain in the tail it is to cope with OpenGL idiosyncracies as they relate to the so-called "standard" GLX interface and the "fun" of getting them to work in the first place... I've set Mail-Followups-To: pointing toward debian-devel-games which seems like a more appropriate forum.. -- Joseph Carter <knghtbrd@d2dc.net> Free software developer * cesarb wonders if in less than a week Carmack will end up receiving in e-mail a courtesy copy of a version of the Quake source which is four times faster than what went out of his virtual hands...
Attachment:
pgpXYtAkQo0JX.pgp
Description: PGP signature