Pedro Rosa <[EMAIL PROTECTED]> writes:
> > The support for Voodoo is not here yet in Cooker. That fact is that to
> > build the DRI stuff for XFree-4 we need a more recent Glide library then
> > the one which is currently in Cooker; Yoann is working to get that, but
> > apparently the guys do not release often so he has to extract stuff from
> > CVS and it takes time to do this in a somewhat stable fashion.
> >
> Well I've been trying to wake up this dri stuff on my own hands. It
> seems that there is a long cat's tail well behind this.
I'm no expert to that -- but what I understood from XFree-4 builds is that
it normally will build the *dri things, provided they can gain access to
the required libs, and for the 3dfx stuff they need libglide.
[...]
> > > In the meantime I tried to use Quake2 in gl (do not confuse with glx)
> > > mode. libGL.so does not work with it. This didn't happen before.
> >
> > Francois? (I don't see clearly the "do not confuse with glx"; to me you
> > can not anymore get any acceleration without glx/dri).
> Tu me demande se je suis de France? Non je suis portugais. Excuse mon
No, I was CC-ing to another employee here who is named Francois (fpons@),
and who wrote the wrapper, so I was asking his opinion. He's in vacation
until tomorrow, that's why he yet did not answered.
[...]
> > Yes, because we have to choose glide or utah-glx (this is for xf-3)
> > (according to giuseppe ghibo); and glide is supposedly supported through
> > the tdfx_dri with xf-4.
> >
> Yeap. Unfortunately there is something real wrong with this tdfx_dri...
> X does not seem to have it. Rebuilding X shows several *_dri.so drivers
> but no tdfx. Even DRI from CVS on sourceforge does not seem to compile
> it. However DRI docs talk about its existence. And even say to turn off
> DRI support on the kernel (why?). Could you give some hints about this?
The same as before -- it's include in XF4 sources but needs some libs to
achieve compile.
[...]
> > His wrapper is supposed to dynamically load the correct stuff; his way of
> > doing the things make even Quake3 work, whereas the Redhat wrapper fails
> > in that issue.
> >
> Well the wrapper is cool stuff. But I don't see the point... I made a
> more correct linking and left the wrapper on libGL.so.1. It seems to
> work as before.
Francois?
> > It has been successfully tested with i810 and ati-mach64, for the moment.
> > The acceleration with i810 (with a p3-733, ok) is pretty impressive (q3
> > with all things turned to full quality).
> i810? How stable?
pretty stable! and rock fast compared to what was expected..
[...]
> > Mo :-) we (mostly Francois) are working hard to provide a Real Gamers
> > Distribution for the 7.2 :-)).
> Any help needed? Really I can kill a few hours because GL is BADLY
> NEEDED. In any case I can test it even on non-gamer apps that use GL as
> a base. There speed may not be so critical but things are still too
> slow. Besides here we have several machines and boards on Linux. Most of
> them Celleron & PII. In a month some PIII and Athlon should come in.
> Motherboards are mostly IBM, Asus & Abit. We have uni and dual-proc
> machinery. Videocards range from a stupid S3Trio to TNT2. Besides I have
> access to a GeForce card. And half-staff is Linux fan (the other half
> you may guess). If your problem is testing...
Well, this kind of help is pretty much needed and we welcome with pleasure
everything you can do with us. I think Francois/other guys shall tell
you/cooker when next things will be sorted out. We will surely need
testing in the upcoming month of stabilizing our next release.
[...]
> > What is the problem with svgalib? It works fine here for 7.0 and 7.1.
> Right. For 7.0 & 7.1. On cooker post-7.1 (well, people are reading a new
> distro right?) things crash badly on VESA option (comp freezes
> sometimes) and show some funny effects on BANSHEE option (magenta screen
> at start of SVGALIB app, console trashed). Similar things happen with
> the lastest tarball of svgalib btw. But this time, the comp doesn't
> freeze anymore. For info the comp is a dual Celleron 300a speeded up to
> 450Mhz on Abit BP6 128M with Voodoo3 3000+Voodoo Graphics board
> (hardware never showed any conflicts for half year). I tested this
> situation on one latest build of mandrake kernel & 2.4.0-test* kernels.
svgalib has not changed since 7.1, execpt a recompile by myself to add
some %config(noreplace) stuff where needed, and to change the default
mouse from serial-ms to ps/2.
it's therefore improbable that it broke up since 7.1 ; and having some
300mhz comps working at 450mhz is surely a way that should be
investigated..
--
Guillaume Cottenceau -- Distribution Developer for MandrakeSoft
http://www.mandrakesoft.com/~gc/
