Re: LSB bastards
On Sun, Jul 01, 2001 at 07:14:09AM -0700, Joseph Carter wrote:
> 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.
I have found installing OpenGL enabling hardware rendering on a Debian
system extremely easy for DRI-supported cards as well as nVIDIA.
You need the kernel modules; but those can be pre-compiled, and compiling
them isn't that tough anyway. Then, if you already have X setup, it's just:
apt-get install xlibmesa3 (and libglide3 for Voodoo 3)
and then make sure that XF86Config-4 specifies to load the modules "dri"
and "glx" (it usually does already) and that it has the section:
Section "DRI"
Mode 0666
EndSection
That's it, for DRI cards. I've managed to get quite a number of people's
installations working with just that procedure. The biggest confusion
seems to be between Kernel Modules and XFree86 Modules, but that can be
resolved simply by clear specification. (tdfx kernel module and
tdfx XFree86 module.. etc)
As for nVIDIA, I've set them up using the nvidia-glx-src and nvidia-kernel-src
packages which retrieve the drivers and set them up in such a way to
facilitate the creation of Debian packages. One make-kpkg, and one
debuild later, you've got two debs to install, then you simply change
the Driver in XF86Config-4 to "nvidia" and you're set to go.
It's come a long long way from the bad old days of XFree86 3 and pre-DRI,
thankfully.
Unfortunately this doesn't help for non-DRI-supported cards, or non-nVIDIA
cards, in which case you've got a mess on your hands.
I know this is a bit of a digression from the main topic, but it seems
you've already taken the liberty to point this at debian-devel-games ;)
>
> 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...
>
--
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Matthew Danish email: mdanish@andrew.cmu.edu ;;
;; OpenPGP public key available from: 'finger mrd@db.debian.org' ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Reply to: