I have an nvidia GeForce2 MX/MX 400 with Suse 8.1. It worked, both with the open driver or the nvidia supplied one, hardware accel et al. Then I upgraded the kernel to the one suplied by suse to solve the known freezing problem with reiserfs (ie k_deflt-2.4.19-174 and kernel-source-2.4.19.SuSE-115). But that forced me to use the "nv" or open driver, because the nvidia one failed. Well, I thought, it's just that it needs recompiling the kernel module, but I left it at that, I didn't need hardware accel at the moment. But I'm trying to set it up again to the nvidia driver (I want to play some games) and it is impossible - sax2, manual, using the old XF86Config that worked 4 months ago... no go. It works (I get the nvidia logo), but horribly slow: gears shows 5 or even 25 seconds per frame - no kidding. Even menus are slowwww... like half a minute sometimes to get the menu. The readme mentions that there could be some wrong links for glx libraries - but no, they are correct. lddconfig, depmod, sax2, suseconfig: no use. swith2nvidia, same. I tried installing the newest rpms: NVIDIA_GLX-1.0-4363.suse81.i586.rpm NVIDIA_kernel-1.0-4363.suse81.i586.rpm Impossible. The kernel modules do not have the sources to compile for my kernel (ie, directory "/usr/src/kernel-modules/nv_glx/" is missing), so it doesn't even start (the binary must be set for the shipped kernel on CD). So I try NVIDIA-Linux-x86-1.0-4363.run. It does install, and offers to compile kernel module, but the end result is the same: horribly slow. So... I'm open to sugestions. The only idea I have left is to downgrade to the kernel that came with the CDs, that is, the one that crashes with resiserfs (barrier code). -- Cheers, Carlos Robinson
Impossible. The kernel modules do not have the sources to compile for my kernel (ie, directory "/usr/src/kernel-modules/nv_glx/" is missing), so it doesn't even start (the binary must be set for the shipped kernel on CD). So I try NVIDIA-Linux-x86-1.0-4363.run. It does install, and offers to compile kernel module, but the end result is the same: horribly slow.
So... I'm open to sugestions.
The only idea I have left is to downgrade to the kernel that came with the CDs, that is, the one that crashes with resiserfs (barrier code).
-- Cheers, Carlos Robinson
Where are the symlinks pointing in /usr/lib/libGL* la /usr/lib/libGL* lrwxrwxrwx 1 root root 10 2003-05-10 07:02 /usr/lib/libGL.so -> libGL.so.1 lrwxrwxrwx 1 root root 17 2003-05-10 07:02 /usr/lib/libGL.so.1 -> libGL.so.1.0.4363 -rwxr-xr-x 1 root root 413588 2003-05-10 07:02 /usr/lib/libGL.so.1.0.4363 lrwxrwxrwx 1 root root 13 2003-05-10 06:12 /usr/lib/libGLU.so.1 -> libGLU.so.1.3 -rwxr-xr-x 1 root root 702207 2003-03-17 06:40 /usr/lib/libGLU.so.1.3 lrwxrwxrwx 1 root root 21 2003-05-10 07:02 /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.4363 -rwxr-xr-x 1 root root 4897272 2003-05-10 07:02 /usr/lib/libGLcore.so.1.0.4363 Also, what's actually in /usr/lib/GL/* And la /usr/X11R6/lib/libXvMCN* -r--r--r-- 1 root root 140644 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.a lrwxrwxrwx 1 root root 18 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so -> libXvMCNVIDIA.so.1 lrwxrwxrwx 1 root root 25 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so.1 -> libXvMCNVIDIA.so.1.0.4363 -rwxr-xr-x 1 root root 134072 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.4363 lrwxrwxrwx 1 root root 25 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.4363 And one more time (sheesh the new config is a pain): la /usr/X11R6/lib/libXv* -rw-r--r-- 1 root root 14720 2003-03-17 05:26 /usr/X11R6/lib/libXv.a lrwxrwxrwx 1 root root 12 2003-05-10 18:34 /usr/X11R6/lib/libXv.so.1 -> libXv.so.1.0 -rwxr-xr-x 1 root root 18494 2003-03-17 05:29 /usr/X11R6/lib/libXv.so.1.0 -rw-r--r-- 1 root root 6792 2003-03-17 05:26 /usr/X11R6/lib/libXvMC.a -r--r--r-- 1 root root 140644 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.a lrwxrwxrwx 1 root root 18 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so -> libXvMCNVIDIA.so.1 lrwxrwxrwx 1 root root 25 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so.1 -> libXvMCNVIDIA.so.1.0.4363 -rwxr-xr-x 1 root root 134072 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.4363 lrwxrwxrwx 1 root root 25 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.4363 Because: la /usr/lib/GL/* -rwxr-xr-x 1 root root 571297 2003-03-17 05:29 /usr/lib/GL/libGL.so.1.2.xf86_glx -rwxr-xr-x 1 root root 2105149 2003-03-17 06:40 /usr/lib/GL/libGL.so.1.4.mesasoft Notice!! no more /usr/lib/libGL.so.1.0.4363.nvidia_glx in /usr/lib/GL (as before). It is now more simply in /usr/lib/ as "libGL.so.1.0.4363" which turns up the same resutls with a "whereis" command with whereis libGL.so.1.0.4363 libGL.so.1.0: /usr/lib/libGL.so.1.0.4363 hereis libGL.so.1.0.4363.nvidia_glx libGL.so.1.0.4363: /usr/lib/libGL.so.1.0.4363 So, I have yet to nail this down. But much of the way that nvidia drivers/lib were loaded/configured in SuSE has change and many ot the things are not in the same place. I would double check the readme for Nvidia and then make sure libGL.so.1.2.xf86_glx (or libGL.so.1.4.mesasoft) isn't grabing one of the other lib or symlinks away from the Nvidia drivers. Oh and furthermore, some of the Mantel kernels from his dir on the SuSE ftp site don't play with nvidia driver. Probably because he has optimized the kernel for them - his kernels tend to focus on things other than making nice with NVIDIA. HTH, Curtis :)
On Sunday 11 May 2003 17:48, Curtis Rey wrote:
So, I have yet to nail this down. But much of the way that nvidia drivers/lib were loaded/configured in SuSE has change and many ot the things are not in the same place.
The thing that really seems designed to piss me off is that the XFree86 software drivers for nvidia cards are now the same name as the accelerated nvidia.com drivers. So if you ever upgrade your X server for whatever reason, then - since the new installer isn't in rpm form - it will simply overwrite them. I just spent a freaking *hour* tracking that one down. sheesh
On Sunday 11 May 2003 06:53, Anders Johansson wrote:
On Sunday 11 May 2003 17:48, Curtis Rey wrote:
So, I have yet to nail this down. But much of the way that nvidia drivers/lib were loaded/configured in SuSE has change and many ot the things are not in the same place.
The thing that really seems designed to piss me off is that the XFree86 software drivers for nvidia cards are now the same name as the accelerated nvidia.com drivers. So if you ever upgrade your X server for whatever reason, then - since the new installer isn't in rpm form - it will simply overwrite them.
I just spent a freaking *hour* tracking that one down. sheesh
Oh, great. That's right. Tarballs can be kinda destructive. Nice if you have a kludge setup. Wipe the old stuff and then tarballs generally overwrite anything missed, etc. But.... if your setup is tweaked or customized then you can get screwed - this is what I meant when referring to "nvidia hell". Yes, this new advent could to out to be the 10th level of hell if not careful.. Oh well. I have been eyeing the ATI cards, but that driver situation isn't much better IMHO. Cheers Curtis :-/ :-)
So I try NVIDIA-Linux-x86-1.0-4363.run. It does install, and offers
to compile kernel module, but the end result is the same: horribly slow.
Oh one other thing concerning this. There is an option to have the *.run for nvidia to just DL and unpack the packages. I remember reading it on one of the READMEs on the nVidia site. So, if you need to try to install the tarballs ( I suspect that's what they are) or look at the make files this might be and option also. Cheers, Curtis.
The 03.05.11 at 08:48, Curtis Rey wrote:
Where are the symlinks pointing in /usr/lib/libGL*
I was going to say that the same as yours, but now I'm seeing an error:
lrwxrwxrwx 1 root root 17 2003-05-10 07:02 /usr/lib/libGL.so.1 -> libGL.so.1.0.4363 -rwxr-xr-x 1 root root 413588 2003-05-10 07:02 /usr/lib/libGL.so.1.0.4363 lrwxrwxrwx 1 root root 13 2003-05-10 06:12 /usr/lib/libGLU.so.1 -> libGLU.so.1.3 -rwxr-xr-x 1 root root 702207 2003-03-17 06:40 /usr/lib/libGLU.so.1.3 lrwxrwxrwx 1 root root 21 2003-05-10 07:02 /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.4363 -rwxr-xr-x 1 root root 4897272 2003-05-10 07:02 /usr/lib/libGLcore.so.1.0.4363
Same as yours: /usr/lib/libGL.so -> libGL.so.1 /usr/lib/libGL.so.1 -> libGL.so.1.0.4363 /usr/lib/libGL.so.1.0.4363 /usr/lib/libGLU.a /usr/lib/libGLU.la /usr/lib/libGLU.so -> libGLU.so.1.3 /usr/lib/libGLU.so.1 -> libGLU.so.1.3 /usr/lib/libGLU.so.1.3 /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.3123 /usr/lib/libGLcore.so.1.0.3123 They should all be version 3123, but after so many tests I did, I see some of the newer version files are there - version 3123 worked before I updated the kernel. Ok, I'll correct that and report results tomorrow :-)
So, I have yet to nail this down. But much of the way that nvidia drivers/lib were loaded/configured in SuSE has change and many ot the things are not in the same place.
I noticed. But I'm reverting to the older version.
I would double check the readme for Nvidia and then make sure libGL.so.1.2.xf86_glx (or libGL.so.1.4.mesasoft) isn't grabing one of the other lib or symlinks away from the Nvidia drivers. Oh and furthermore, some of the Mantel kernels from his dir on the SuSE ftp site don't play with nvidia driver. Probably because he has optimized the kernel for them - his kernels tend to focus on things other than making nice with NVIDIA.
But I'm not using a Mantel kernel, but a standard one (ie, an official patch). -- Cheers, Carlos Robinson
The 03.05.11 at 08:48, Curtis Rey wrote:
Where are the symlinks pointing in /usr/lib/libGL*
-rw-r--r-- root root 602624 Sep 10 02 /usr/lib/libGL.a /usr/lib/libGL.so -> libGL.so.1 /usr/lib/libGL.so.1 -> GL/libGL.so.1.0.3123.nv_glx -rw-r--r-- root root 4412898 Sep 10 02 /usr/lib/libGLU.a -rwxr-xr-x root root 780 Sep 10 02 /usr/lib/libGLU.la /usr/lib/libGLU.so -> libGLU.so.1.3 /usr/lib/libGLU.so.1 -> libGLU.so.1.3 -rwxr-xr-x root root 680548 Sep 10 20 /usr/lib/libGLU.so.1.3 /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.3123 -rwxr-xr-x root root 623820 Sep 16 02 /usr/lib/libGLcore.so.1.0.3123 They are correct now, but using version 3123.I did try version 4363 yesterday: in all cases, it was painfully slow. Right now, I'm using a text console, X with "nvidia" is unusable, I'll switch to "nv" right after writing this email.
Also, what's actually in /usr/lib/GL/*
283444 Sep 16 2002 /usr/lib/GL/libGL.so.1.0.3123.nv_glx 551468 Sep 10 2002 /usr/lib/GL/libGL.so.1.2.xf86_glx 2022753 Sep 10 2002 /usr/lib/GL/libGL.so.1.3.mesasoft
And la /usr/X11R6/lib/libXvMCN*
/usr/X11R6/lib/libXvMCNVIDIA.so -> libXvMCNVIDIA.so.1 /usr/X11R6/lib/libXvMCNVIDIA.so.1 -> libXvMCNVIDIA.so.1.0.4363 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.4363 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.4363
I have: 129758 2002-09-16 09:50 /usr/X11R6/lib/libXvMCNVIDIA.a 124544 2002-09-16 09:50 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.3123 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.3123 129758 Sep 16 2002 /usr/X11R6/lib/libXvMCNVIDIA.a 124544 Sep 16 2002 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.3123 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.3123 Perhaps I have two missing symlink, libXvMCNVIDIA.so. Done: /usr/X11R6/lib/libXvMCNVIDIA.a /usr/X11R6/lib/libXvMCNVIDIA.so -> libXvMCNVIDIA.so.1 /usr/X11R6/lib/libXvMCNVIDIA.so.1 -> libXvMCNVIDIA.so.1.0.3123 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.3123 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.3123 I'll try startx in a moment, after checking the rest of your list :-)
And one more time (sheesh the new config is a pain):
la /usr/X11R6/lib/libXv* -rw-r--r-- 1 root root 14720 2003-03-17 05:26 /usr/X11R6/lib/libXv.a lrwxrwxrwx 1 root root 12 2003-05-10 18:34 /usr/X11R6/lib/libXv.so.1 -> libXv.so.1.0 -rwxr-xr-x 1 root root 18494 2003-03-17 05:29 /usr/X11R6/lib/libXv.so.1.0 -rw-r--r-- 1 root root 6792 2003-03-17 05:26 /usr/X11R6/lib/libXvMC.a -r--r--r-- 1 root root 140644 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.a lrwxrwxrwx 1 root root 18 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so -> libXvMCNVIDIA.so.1 lrwxrwxrwx 1 root root 25 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so.1 -> libXvMCNVIDIA.so.1.0.4363 -rwxr-xr-x 1 root root 134072 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.4363 lrwxrwxrwx 1 root root 25 2003-05-10 07:02 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.4363
I only have: /usr/X11R6/lib/libXvMCNVIDIA.a /usr/X11R6/lib/libXvMCNVIDIA.so -> libXvMCNVIDIA.so.1 /usr/X11R6/lib/libXvMCNVIDIA.so.1 -> libXvMCNVIDIA.so.1.0.3123 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.3123 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.3123 I don't have /usr/X11R6/lib/libXv.a, nor libXvMC.a, but those are provided by xdevel-4.2.0-176.i586.rpm, which I have installed, but the file must have been deleted today when I reinstalled a few rpms. Ugh. libXv.so.1.0 seems to belong to XFree86-compat-libs.rpm, which I don't have installed. I'll install it, just in case. Ok, I fire Yast right now on another console (ncurses mode). [...] Now I have: /usr/X11R6/lib/libXv.a /usr/X11R6/lib/libXv.so.1 -> libXv.so.1.0 /usr/X11R6/lib/libXv.so.1.0 /usr/X11R6/lib/libXvMC.a /usr/X11R6/lib/libXvMCNVIDIA.a /usr/X11R6/lib/libXvMCNVIDIA.so -> libXvMCNVIDIA.so.1 /usr/X11R6/lib/libXvMCNVIDIA.so.1 -> libXvMCNVIDIA.so.1.0.3123 /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.3123 /usr/X11R6/lib/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.1.0.3123 That seems correct.
Because: la /usr/lib/GL/* -rwxr-xr-x 1 root root 571297 2003-03-17 05:29 /usr/lib/GL/libGL.so.1.2.xf86_glx -rwxr-xr-x 1 root root 2105149 2003-03-17 06:40 /usr/lib/GL/libGL.so.1.4.mesasoft
I have /usr/lib/GL/libGL.so.1.0.3123.nv_glx /usr/lib/GL/libGL.so.1.2.xf86_glx /usr/lib/GL/libGL.so.1.3.mesasoft
Notice!! no more /usr/lib/libGL.so.1.0.4363.nvidia_glx in /usr/lib/GL (as before). It is now more simply in /usr/lib/ as "libGL.so.1.0.4363"
Well, as I have the older version, I still have it. I'm using the older version, because it worked perfectly a few months ago. It stopped working when I installed the kernel patch that solved the problem with reiserfs freezes.
which turns up the same resutls with a "whereis" command with whereis libGL.so.1.0.4363 libGL.so.1.0: /usr/lib/libGL.so.1.0.4363
hereis libGL.so.1.0.4363.nvidia_glx libGL.so.1.0.4363: /usr/lib/libGL.so.1.0.4363
nimrodel:~ # whereis libGL.so.1.0 libGL.so.1: /usr/lib/libGL.so.1 But: nimrodel:~ # locate nvidia_glx /usr/bin/3Ddiag.nvidia_glx /usr/X11R6/bin/switch2nvidia_glx Mine is nv_glx: nimrodel:~ # l /usr/lib/GL/libGL.so.1.0.3123.nv_glx -rwxr-xr-x 1 root root 283444 Sep 16 2002 /usr/lib/GL/libGL.so.1.0.3123.nv_glx* However: nimrodel:~ # whereis libGL.so.1.0.3123.nv_glx libGL.so.1.0.3123: Something missing there :-? Mmm. There is a bug mentioned in whereis doc: | whereis has a hard-coded path, so may not always find what you're | looking for. Ok, I'll postpone this email, just in case, and try startx after those changes. [...] No good: it took minutes to start, and then very slow afterward. It most be something else: my guess is the kernel.
So, I have yet to nail this down. But much of the way that nvidia drivers/lib were loaded/configured in SuSE has change and many ot the things are not in the same place.
I noticed.
I would double check the readme for Nvidia and then make sure libGL.so.1.2.xf86_glx (or libGL.so.1.4.mesasoft) isn't grabing one of the other lib or symlinks away from the Nvidia drivers.
Yes, I read carefully appendix C: |> Q: Why do OpenGL applications run so slow? |> |> A: The application is probably using a different library still on your |> system, rather than the NVIDIA supplied OpenGL library. Please see |> APPENDIX C for details.
Oh and furthermore, some of the Mantel kernels from his dir on the SuSE ftp site don't play with nvidia driver. Probably because he has optimized the kernel for them - his kernels tend to focus on things other than making nice with NVIDIA.
No, this is a patched, official kernel: kernel-source-2.4.19.SuSE-115 k_deflt-2.4.19-174 The ones on the dvd were: k_deflt-2.4.19-74.i586.rpm kernel-source-2.4.19.SuSE-49.i586.rpm I'm thinking of either downgrading the kernel (with barrier code deactivated on fstab), or upgrading to 2.4.20 from mantel. I saw this morning on the .X.err some mention of mutex not being found. I did a "locate mutex", and among other things I saw: /usr/src/linux-2.4.19.SuSE/drivers/acpi/executer/.exmutex.o.flags /usr/src/linux-2.4.19.SuSE/drivers/acpi/executer/exmutex.c /usr/src/linux-2.4.19.SuSE/drivers/acpi/executer/exmutex.o So it occurred to me to boot with apic enabled. I had to disable apic some months ago, because the USB failed to work if APIC was enabled. To my surprise, the scanner now works with apic enabled :-O but no nvidia, I mean, it remains slow as a garden snake - and this is a PIV with 3/4 Gb. As the system I think is faster with APIC enabled, I'm reluctant to downgrade... Ugh. Well, I'll have to think about Mr Mantel kernel :-) -- Cheers, Carlos Robinson
They are correct now, but using version 3123.I did try version 4363 yesterday: in all cases, it was painfully slow. Right now, I'm using a text console, X with "nvidia" is unusable, I'll switch to "nv" right after writing this email.
Also, what's actually in /usr/lib/GL/*
283444 Sep 16 2002 /usr/lib/GL/libGL.so.1.0.3123.nv_glx 551468 Sep 10 2002 /usr/lib/GL/libGL.so.1.2.xf86_glx
DANGER, DANGER WILL ROBINSON (lost in space phrase)! 2022753 Sep 10 2002 /usr/lib/GL/libGL.so.1.3.mesasoft Loose this now. Mesasoft drivers have caused me nothing but grief with nvidia drivers and many howto sites (and I believe nvidia) state that this is a conflict. This is most like the cause of the problems. if you try and rpm -e mesasoft rpm will complain that the other dependent packages need this driver - not true! just rm it for the /usr/lib/GL dir directly. I am willing to bet this is the source of your problems and if you think about it the slow video response is most likely on the order of the mesasoft GL performance! The other option is to point the games / 3D apps to look for the nvidia drivers. Many state that this is the case, like the original Quake 3 with "Quake3 +set gl_r /usr/lib/GL/libGL.so.1.0.4363.nv_glx" and then Quake 3 flies. The same can be said about many linux games and apps. They are set to default to mesasoft if they can't find anyother drivers - generally they point to libGL.so and stop looking. I suspect that indeed the mesasoft drivers are steal things away regardless that the symlinks say otherwise. You might also rm the mesasoft drivers and then manually re symlink libGL.so to libGL.so.1, etc. Like I said. I always loose the mesasoft drivers first think - they're antiques, they're slow, and almost always in the way and a conflict. Try this and get back to us to let us know - well kick this in the butt yet :) ! Cheers, Curtis.
The 03.05.12 at 20:02, Curtis Rey wrote:
DANGER, DANGER WILL ROBINSON (lost in space phrase)! 2022753 Sep 10 2002 /usr/lib/GL/libGL.so.1.3.mesasoft
What's that? (The lost in space part, I mean - movie titles get translated, so I don't know which one is that, or I don't remember)
Loose this now. Mesasoft drivers have caused me nothing but grief with nvidia drivers and many howto sites (and I believe nvidia) state that this is a conflict. This is most like the cause of the problems. if you try and rpm -e mesasoft rpm will complain that the other dependent packages need this
Ok, done. run: switch2nvidia switch2nvidia_glx cp /etc/X11/XF86Config.nvidia.20030511 /etc/X11/XF86Config /sbin/depmod /sbin/ldconfig and finally, reboot, init 3, startx (from a console). It takes something like three or four minutes till I get kde running - I'm not kidding, when I think it has hanged, I boot up my old pentium 120 w 32 Mb, and I have time to ssh into this one before kde is finished and accepting input. By the way, response to ssh is fast, but inside kde even the mouse gets lost now and then.
driver - not true! just rm it for the /usr/lib/GL dir directly. I am willing to bet this is the source of your problems and if you think about it the slow video response is most likely on the order of the mesasoft GL performance!
It wasn't, I'm afraid. :-( Remember that this machine had nvidia working last december with the same software - except upgrades. Mesasoft was there from the very begining.
The other option is to point the games / 3D apps to look for the nvidia drivers. Many state that this is the case, like the original Quake 3 with
I want nvidia working to play games, but I can't even use kde or gnome. It works perfect now with the open driver (nv), but horrible with the closed "nvidia".
Like I said. I always loose the mesasoft drivers first think - they're antiques, they're slow, and almost always in the way and a conflict. Try this and get back to us to let us know - well kick this in the butt yet :) !
Good try, but didn't work out. I'm going to try to downgrade the kernel, and see what happens - it's faster for me than updating to a mantel kernel, because 35 Mb on a modem is a lot. If it works, then I'll think about upgrading. Afterthought: This is the report of 3Ddiag: 3Ddiag version 0.496 Verifying 3D configuration: Using 3dinfo ************************************************************ Verifying 3D configuration based on XFree86 4 for 3D board "nVidia Corporation GeForce2 MX/MX 400 (10de@0110)": Tests for package "NVIDIA_GLX": package ... done. package files ... done. Tests for package "NVIDIA_kernel": package ... done. package files ... done. Tests for correct OpenGL libraries/GLX extensions: Symbolic Links ... done. /etc/sysconfig/3ddiag (SCRIPT_3D=switch2nvidia_glx) ... done. Test for correct XFree86 version ... done. Tests for XFree86 configuration: Config File /etc/X11/XF86Config ... done. Driver ... done. Color Depth ... done. Extensions ... done. Options ... done. ----------------------- NOTE ----------------------------------- If 3D hardware OpenGL configuration is not stable enough, you should switch back to 'Mesa Software Rendering'. You can verify this configuration with the command "3Ddiag --mesasoft". ----------------------- NOTE ----------------------------------- Checking GLU/glut runtime configuration: GLU ... done (package mesaglu) glut ... done (package mesaglut) nimrodel:~ # 3dinfo nVidia Corporation GeForce2 MX/MX 400 (10de@0110):4:nvidia:16:glx:::NVIDIA_GLX,NVIDIA_kernel:switch2nvidia_glx -- Cheers, Carlos Robinson
Quoting Carlos E. R.
The 03.05.12 at 20:02, Curtis Rey wrote:
DANGER, DANGER WILL ROBINSON (lost in space phrase)! 2022753 Sep 10 2002 /usr/lib/GL/libGL.so.1.3.mesasoft
What's that? (The lost in space part, I mean - movie titles get translated, so I don't know which one is that, or I don't remember)
Lost in Space was a US TV show. IIRC, it was made into a movie and I am sure the phrase survived. The phrase was said by the robot/chaperon as the boy, Will Robinson, was about to do something foolhardy. HTH, Jeffrey
On Tuesday 13 May 2003 07:54, Carlos E. R. wrote:
The 03.05.12 at 20:02, Curtis Rey wrote:
DANGER, DANGER WILL ROBINSON (lost in space phrase)! 2022753 Sep 10 2002 /usr/lib/GL/libGL.so.1.3.mesasoft
What's that? (The lost in space part, I mean - movie titles get translated, so I don't know which one is that, or I don't remember)
Loose this now. Mesasoft drivers have caused me nothing but grief with nvidia drivers and many howto sites (and I believe nvidia) state that this is a conflict. This is most like the cause of the problems. if you try and rpm -e mesasoft rpm will complain that the other dependent packages need this
Ok, done. run: switch2nvidia switch2nvidia_glx cp /etc/X11/XF86Config.nvidia.20030511 /etc/X11/XF86Config /sbin/depmod /sbin/ldconfig
and finally, reboot, init 3, startx (from a console).
It takes something like three or four minutes till I get kde running - I'm not kidding, when I think it has hanged, I boot up my old pentium 120 w 32 Mb, and I have time to ssh into this one before kde is finished and accepting input. By the way, response to ssh is fast, but inside kde even the mouse gets lost now and then.
driver - not true! just rm it for the /usr/lib/GL dir directly. I am willing to bet this is the source of your problems and if you think about it the slow video response is most likely on the order of the mesasoft GL performance!
It wasn't, I'm afraid. :-(
Remember that this machine had nvidia working last december with the same software - except upgrades. Mesasoft was there from the very begining.
The other option is to point the games / 3D apps to look for the nvidia drivers. Many state that this is the case, like the original Quake 3 with
I want nvidia working to play games, but I can't even use kde or gnome. It works perfect now with the open driver (nv), but horrible with the closed "nvidia".
Like I said. I always loose the mesasoft drivers first think - they're antiques, they're slow, and almost always in the way and a conflict. Try this and get back to us to let us know - well kick this in the butt yet :) !
Good try, but didn't work out. I'm going to try to downgrade the kernel, and see what happens - it's faster for me than updating to a mantel kernel, because 35 Mb on a modem is a lot. If it works, then I'll think about upgrading.
Ok, lets get smart about this. I have an gf2-mx 200/400 and there were some tricks to getting to to play nice. Also the later versions of SuSE have had some changes with the way the monitors and cards interact and this too gave me some problems One other thing. Have you tried to boot into another wm? Something like Blackbox, XFCE, Wmaker, etc.. does the same thing happen? Need to see if this is an nvidia thing, a kde thing or what. I'll look at some files and readmes and see about some XFConfig options - I remember this seemed to help alot - especially with the card to monitor issues. EDIDs and AGP settings, etc. Get back to you soon. Cheers, Curtis.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 12 May 2003 22:02, Curtis Rey wrote:
They are correct now, but using version 3123.I did try version 4363 yesterday: in all cases, it was painfully slow. Right now, I'm using a text console, X with "nvidia" is unusable, I'll switch to "nv" right after writing this email.
Also, what's actually in /usr/lib/GL/*
283444 Sep 16 2002 /usr/lib/GL/libGL.so.1.0.3123.nv_glx 551468 Sep 10 2002 /usr/lib/GL/libGL.so.1.2.xf86_glx
DANGER, DANGER WILL ROBINSON (lost in space phrase)! 2022753 Sep 10 2002 /usr/lib/GL/libGL.so.1.3.mesasoft
Loose this now. Mesasoft drivers have caused me nothing but grief with nvidia drivers and many howto sites (and I believe nvidia) state that this is a conflict. This is most like the cause of the problems. if you try and rpm -e mesasoft rpm will complain that the other dependent packages need this driver - not true! just rm it for the /usr/lib/GL dir directly. I am willing to bet this is the source of your problems and if you think about it the slow video response is most likely on the order of the mesasoft GL performance!
The other option is to point the games / 3D apps to look for the nvidia drivers. Many state that this is the case, like the original Quake 3 with "Quake3 +set gl_r /usr/lib/GL/libGL.so.1.0.4363.nv_glx" and then Quake 3 flies. The same can be said about many linux games and apps. They are set to default to mesasoft if they can't find anyother drivers - generally they point to libGL.so and stop looking. I suspect that indeed the mesasoft drivers are steal things away regardless that the symlinks say otherwise. You might also rm the mesasoft drivers and then manually re symlink libGL.so to libGL.so.1, etc.
Like I said. I always loose the mesasoft drivers first think - they're antiques, they're slow, and almost always in the way and a conflict. Try this and get back to us to let us know - well kick this in the butt yet :) !
Cheers, Curtis.
Hey Curtis, Do you think this could be a possible reason none of the (GL) screensavers work for me in 8.2? Everything else 3D works fine, literally. Games, video, etc, are doing great, and I have the mesa stuff installed (along with the nvidia drivers too of course), the only thing that's not working video-wise, is all the GL screensavers...oh, and almost *none* of them have any configuration (a dialogue pops up telling me there's no configuration for <whatever screensaver> ), I've only found 3 that lets me configure them. Sorry if this is hijacking the post, but I figure your answer above may have something to do with my trouble too. John - -- A butterfly is: Pretty,soft,harmless...and useless, just like M$N. My Penguin eats butterflies. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE+wRwjH5oDXyLKXKQRAi5VAJ4hQsAIPmHtxwRjIJS6B2aBatlN0QCfUidZ iBE33laiFR0LhQpvP3Ek7io= =M8hK -----END PGP SIGNATURE-----
Hey Curtis,
Do you think this could be a possible reason none of the (GL) screensavers work for me in 8.2? Everything else 3D works fine, literally. Games, video, etc, are doing great, and I have the mesa stuff installed (along with the nvidia drivers too of course), the only thing that's not working video-wise, is all the GL screensavers...oh, and almost *none* of them have any configuration (a dialogue pops up telling me there's no configuration for <whatever screensaver> ), I've only found 3 that lets me configure them. Sorry if this is hijacking the post, but I figure your answer above may have something to do with my trouble too.
John
To be honest I am still trying to figure this one out. Many thinks have changed or are different in 8.2. The GL config and other peripheries to the way the video system is configurable is different. I chalk it up to X4.3, KDE 3.1, and the very new way SuSE has configured and built the OS. Case in point for GL the nvidia_glx drivers no longer reside in /usr/lib/GL as they did in the previous version. On another point, have you looked and compared the the /usr/local is setup compared to previous version? I mean before 8.2 this dir and it's subdirs were essentially empty. Now there is an almost complete mirror or copy of the / (root) directory and subdirectories in the. For example: /dev vs. /usr/local/dev or /usr/lib vs. /usr/local/lib I don't know if this has any ramifications or effects on how the system is configured and how things interact. I have to look in to this. So I really can't say myself about the reason why some screensavers are or aren't working, configurable, and to what they're looking at or for to operate. If I get any insight to this I will surely post. It may take a bit of time to dig into this thought. Cheers, Curtis.
On Tuesday 13 May 2003 22:09, Curtis Rey wrote:
To be honest I am still trying to figure this one out. Many thinks have changed or are different in 8.2. The GL config and other peripheries to the way the video system is configurable is different. I chalk it up to X4.3, KDE 3.1, and the very new way SuSE has configured and built the OS.
Hi, I had these problems with 8.1 and X4.2 so maybe the problem is with KDE 3.1. The comments over at the nvidia linux forum seem to show that this isn't distro specific. The SuSE upgrade 2.4.19 kernel caused me 2 days of frustration and I would have gone back to the standard 2.4.19 if I had had my cd's here but the Mantel 2.4.20 works as well if not better. I hope this helps to narrow the search down a little. Good luck Mike Ayers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 13 May 2003 15:09, Curtis Rey wrote: <snip>
To be honest I am still trying to figure this one out. Many thinks have changed or are different in 8.2. The GL config and other peripheries to the way the video system is configurable is different. I chalk it up to X4.3, KDE 3.1, and the very new way SuSE has configured and built the OS.
Case in point for GL the nvidia_glx drivers no longer reside in /usr/lib/GL as they did in the previous version.
On another point, have you looked and compared the the /usr/local is setup compared to previous version? I mean before 8.2 this dir and it's subdirs were essentially empty. Now there is an almost complete mirror or copy of the / (root) directory and subdirectories in the. For example:
/dev vs. /usr/local/dev
or
/usr/lib vs. /usr/local/lib
I don't know if this has any ramifications or effects on how the system is configured and how things interact.
I have to look in to this. So I really can't say myself about the reason why some screensavers are or aren't working, configurable, and to what they're looking at or for to operate.
If I get any insight to this I will surely post. It may take a bit of time to dig into this thought.
Cheers, Curtis.
Ugh...I'm so sorry I didn't post earlier, but i found out that for some reason (still unknown), my 3D capabilities just sort of 'went away'. When I did the sh nvidia....run thing, it worked fine, even after restarting the system, then today for the heck of it I try to open pixieplus...nothing happens. I open a konsole and do pixie...and get 'no openGL support installed' or something like that. Huh? So I fire up 3ddiag, and sure enough, no 3D. I open YaST, enable 3D, and all's fine, my screensavers (the GL) ones too, now work (though pixie plus *still* won't give me any options to choose different formats to change a pic to). Again, I'm very sorry I didn't post back earlier that I'd fixed one of the problems, my apologies to all who looked into this and tried to help me figure out what was wrong (though I still wouldn't mind someone figuring out what's wrong with pixie plus, heh). John - -- A butterfly is: Pretty,soft,harmless...and useless, just like M$N. My Penguin eats butterflies. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE+wc2pH5oDXyLKXKQRAsrIAJ9gPBxI2LkBOY9tx4UR0Ttg+VsidQCePfs0 EJz2sAvMWR/emKg8i+HS2zM= =Zds8 -----END PGP SIGNATURE-----
The 03.05.13 at 11:23, John wrote:
Do you think this could be a possible reason none of the (GL) screensavers work for me in 8.2? Everything else 3D works fine, literally. Games, video, etc, are doing great, and I have the mesa stuff installed (along with the nvidia drivers too of course), the only thing that's not working video-wise, is all the GL screensavers...oh, and almost *none* of them have any
Try to start them from an xterm. -- Cheers, Carlos Robinson
participants (6)
-
Anders Johansson -
Carlos E. R. -
Curtis Rey -
Jeffrey L. Taylor -
John -
twopinkblobs＠t-online.de