Bug 203295 - tdfx driver uses DRI, but libGL doesn't find tdfx_dri.so (because it's not shipped)
tdfx driver uses DRI, but libGL doesn't find tdfx_dri.so (because it's not sh...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-20 17:38 EDT by Leszek Matok
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-21 10:00:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Leszek Matok 2006-08-20 17:38:07 EDT
I have a 3dfx Voodoo3 2000, it was working in Xorg 6.8.2 on my FC3, but doesn't
work in FC5. I've skipped FC4, then used nVidia with their drivers, now I want
to have a non-tainted Fedora and guess what - you force me to go back to nVidia
with the proprietary drivers! ;)

In Xorg.0.log I can read:
(II) TDFX(0): [drm] installed DRM signal handler
(II) TDFX(0): [DRI] installation complete
(II) TDFX(0): Direct rendering enabled

So direct rendering is enabled on the server side. But I get flaky glxgears, not
to mention nexuiz or neverball. Quick investigation:
$ setenv LIBGL_DEBUG verbose
$ glxinfo
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 1.1.1 tdfx (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/tdfx_dri.so
libGL error: dlopen /usr/lib/dri/tdfx_dri.so failed (/usr/lib/dri/tdfx_dri.so:
cannot open shared object file: No such file or directory)
libGL error: unable to find driver: tdfx_dri.so
display: :0  screen: 0
direct rendering: No
(...)
So although dri is enabled, libGL needs /usr/lib/dri/tdfx_dri.so, which is not
there.

Recompiling FC5's Mesa after adding tdfx to redhat-mesa-driver-install script
gives me somewhat functional GLX: glxgears work, I can play xmoto, although some
textures are too big (FX_RESCALE_BIG_TEXURES_HACK needed), I can play QuakeForge
just right, but it segfaults on map change, same goes with neverball (too big
textures, segfault after clicking any submenu). The segfaults may be something
between this particular versions of Mesa and Glide, I'm not experienced in
debugging Mesa (but I can run any test you tell me to run).

Glide3 is in Extras, which I read as: it's legal to have Glide in Fedora. IIRC
tdfx Mesa can't even speak to this hardware and uses Glide instead, is this the
reason for tdfx_dri absence in Core? Can tdfx_dri.so come back or somehow be
made part of Extras or can Glide return to Core? Will it come back in newer Mesa?

Version-Release number of selected component (if applicable):
mesa-libGL-6.4.2-6.FC5.3
I've also checked files inside mesa-libGL-6.5-19.fc5.aiglx.i386.rpm and it
doesn't have tdfx_dri.so either. I'd test whole Xorg 7.1 from AIGLX repo if I
only knew it'll work (because if it doesn't, I have to go back to my nVidia, you
know ;)).
Comment 1 Adam Jackson 2006-08-21 10:00:31 EDT
Well that's weird.  We build the tdfx driver but we never install it.

I believe the decision was made to move Glide3 to extras mostly because no one
wanted to maintain it in core.  Ideally someone would get around to rewriting
the tdfx driver to not use glide anymore.  In the meantime I've reenabled
installing the tdfx driver in rawhide, and I'll push a Mesa update for FC-5 to
do the same (should be mesa-libGL-6.4.2-6.fc5.4), which will at least make the
tdfx driver work when Glide3 is installed.

If you're having issues with the tdfx driver they should probably be reported to
upstream Mesa (bugs.freedesktop.org, Mesa component) since we don't modify the
tdfx driver at all in Fedora.

Thanks for the catch!
Comment 2 Leszek Matok 2006-08-21 13:07:19 EDT
Honestly, I don't think anyone is interested in rewriting tdfx to not use Glide
(even if the source is there). There are no new 3dfx cards and current layered
setup worked fine in earlier X/Mesa/Glide.

The segfaults turned out to be caused by tdfxDeleteTexture, which calls _mesa_*
functions, which end up calling _mesa_align_free, which takes address to be
freed from the word right before the pointer, but there's no pointer there.
Probably a driver error, I'll wait for your version to appear in updates-testing
(maybe I did something wrong) and test it.

If the bugs persist and it's Mesa error, can Mesa 6.5 be compiled (by me) for my
Xorg 7.0 under FC5? I don't think they want to hear about bugs in old versions :)
Comment 3 Leszek Matok 2006-08-21 17:27:41 EDT
I did it, Mesa 6.5 crashes as well.

I found the upstream, https://bugs.freedesktop.org/show_bug.cgi?id=7574 and I'm
moving there right away.
Comment 4 Hans de Goede 2006-08-22 16:07:17 EDT
As the Extras Glide3 maintainer I'm happy to hear my hard work is still used by
people :) I have a voodoo2 myself so I've not tested the DRI path, since the
patch attached to: https://bugs.freedesktop.org/show_bug.cgi?id=7574 seems vital
for opengl -> dri to work on voodoo3 / 5 it would be very nice if this patch
could be applied to the Fedora packages (or did we already pick it up from
upstream?)
Comment 5 Leszek Matok 2006-08-22 19:38:12 EDT
Turned out it was fixed in Mesa CVS long time ago, sigh :) This means rawhide
picked it up already.

Note You need to log in before you can comment on or make changes to this bug.