[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LSB bastards

>> Joseph Carter <knghtbrd@d2dc.net> writes:

 > No. that is simple fact.

 No, it's your own experience Joseph.  In your case it's a fact.
 Radeons are more problematic than other cards.

 With really recent versions of everything, dificulty is increasing,
 yes, because everything seems to be desynced and all sides seem to be
 saying "it's someone else's fault". 

 > If you have a DRI-supported card, you must compile not one, but two
 > custom kernel modules for that card on your machine.

 I'm curious about which is the second one... agpgart?  If you've got a
 recent enough kernel it just works.  You can just forget about 2.2
 kernels, the DRM modules don't work there (and won't until someone is
 interested enough to port them back).  Besides, what's on the XFRee86
 tree is not what's on Linus' tree (and neither is always in agreement
 with what's on the DRI tree).  Someone should take a hint and finally
 pack programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and ship
 that alongside whatever package provides the DRI drivers.  Pretending
 that the version in the kernel will work with whatever the packaged
 driver happens to be is just delusional.  It's much more stable now,
 but the next release will probably change the requirement again.
 > (This if you can get the damned thing to work, which I have had very
 > mixed success with..)
 like I said.  Before starting to fiddle with my own binaries, The only
 thing I had to do to get the DRI working was XFree86 -configure and
 compile the kernel module (and at that time the kernel drm module and
 the xfree86 drm module where in agreement so I didn't even need to fish
 the drm out of the xfree86 sources).
 > To add insult to injury, while one set of code works fine for GLX in
 > general, Mesa with a Voodoo2 requires slightly different code.

 if this is the sort of voodoo2 supported by the mesa glide packages, I
 wouldn't midn a patch (TESTED, PLEASE! I won't ever add a patch to that
 package unless the submitter gives some proof that the patch is
 *actually* tested), and I'll forward it.  If it's the other kind of
 voodoo2, sorry, I can't help there.  (And I wouldn't mind something
 more concrete than all this hand waving argumentation -- I stopped
 beleiving in these "trust me, it's way complicated" fairy tales a long
 time ago)
 > Most recently written apps are, fortunately, as long as they were not
 > written for GLUT.

 patches (or technical descriptions of the problem) are welcome.

 > I won't even go into NVidia, whose standard installation is likely to
 > hose something if you're not damned careful.

 funny, I thought there were non-packages of this thing to avoid this
 kind of problem.  I'm no NVIDIA fan, but I have to admit their drivers
 tend to work flawlessly if you know what you are doing (and this
 know-how happens to be expressable via dependencies, conflicts and one

 > 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

 glXGetProcAddressARB is not GLX-version specific.  Any version of the
 GLX extension can implement it.  Mesa does.  The OpenGL SI's GLX does,
 too.  The NVIDIA drivers, too.  Any half decent implementation should.
 It's the only portable way of using extensions.
 > 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.
 NVIDIA GL headers are a pathetic joke.
 > 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.

 that's very very non portable.  Try it on an IRIX implementation.  It
 blows up.  You have to dlopen libgl there (pay attention to case).

 > I don't recall reading they call for GLX.  Have I missed something?

 read the specification.  They probably don't know what GLX is :-) but
 they call for it (implicitly).  At any rate they refer to the Linux
 OpenGL ABI.
 > work in the first place...  I've set Mail-Followups-To: pointing
 > toward debian-devel-games which seems like a more appropriate forum..

 I didn't fiddle with it, promise.  It's still going to d-d.

Marcelo             | Too many people want to *have written*.
mmagallo@debian.org |         -- (Terry Pratchett, alt.fan.pratchett)

Reply to: