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.