3D--My only 8.2 Glitch
My only problem in 8.2 is getting 3D accelleration working correctly. By contrast, 8.1 enabled 3D right out of the box, even prompting me during installation whether I wanted it and then working perfectly. Well, I went into YaST2 and did everything there I could, then I ran sax2 and did the same. Finally I went into the SuSE HelpCenter and searched for 3D and found the article "3D and SuSE Linux" and followed it's instructions to run 3Ddiag. Well, as you can see below, there aren't any error messages that I can see. Here's the output: Verifying 3D configuration based on XFree86 4 for 3D board "Intel Corporation 82810 CGC [Chipset Graphics Controller] (8086@7121)": Tests for package "XFree86-GLX": package ... done. package files ... done. Tests for correct OpenGL libraries/GLX extensions: Symbolic Links ... done. /etc/sysconfig/3ddiag (SCRIPT_3D=switch2xf86_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) Just to cover all the bases, I ran the script switch2xf86_glx (as root) and still the 3D doesn't run correctly in games like tuxracer and tuxkart. At this point the play is choppy and very slow, not like a few days ago while running 8.1. If anyone knows what I should do next, I'd be grateful. -- Bryce Hardy (Santa Rosa, CA) brycehdy@sonic.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tests for correct OpenGL libraries/GLX extensions: Symbolic Links ... done. /etc/sysconfig/3ddiag (SCRIPT_3D=switch2xf86_glx) ... done.
Possibly a silly question - so forgive me. But, did you, as root, run the command in the console "switch2xf86_glx"? Cheers, Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+sImI7WVLiDrqeksRAoI2AKCNZFajP5J6AD4FSegM+xrxqB0N0ACggoYz oCXC7LfK0EVBOdRaAJVP7Xw= =0Cq4 -----END PGP SIGNATURE-----
On Wednesday 30 April 2003 07:42 pm, Curtis Rey wrote:
Possibly a silly question - so forgive me. But, did you, as root, run the command in the console "switch2xf86_glx"?
Yes, you didn't see the end of my original post, I did do that just as a hunch, but still it's not working correctly. -- Bryce Hardy (Santa Rosa, CA) brycehdy@sonic.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 29 April 2003 21:56 pm, Bryce Hardy wrote:
On Wednesday 30 April 2003 07:42 pm, Curtis Rey wrote:
Possibly a silly question - so forgive me. But, did you, as root, run the command in the console "switch2xf86_glx"?
Yes, you didn't see the end of my original post, I did do that just as a hunch, but still it's not working correctly.
OK, my experience with this sometimes boils down more to the way X, the card, and sax work with the monitor. I presume your getting a screen. You may want to look at the monitor settings. I often manually set the monitor params myself or run the x prog that tells you your monitor res timings and cut and past these into the XF86Config file. Also, look at the symlinks for /usr/lib/libGL*. I am used to dealing with nvidia cards and am unsure about what card your using since I haven't seen the 1st post you made. I would make sure the the libGL.so is point to LibGL.so.1 and that to the propers GL driver. Furthermore, you may want to look at /usr/lib/GL so see what other drivers are in there. If you find the mesasoft_glx drivers this may also be a problem because the symlinks may point to that. I have had confilcts with this before. The symlinks and the drivers are often the issue. If you try to "rpm -e mesa" or the mesasoft (can't remember exactly but I think it "rpm -e mesasoft") and it complains about the dependencies with the mesa libs (keeping the mesa libs isn't a prob in my experience) then you can just manually rm the mesasoft drivers in the /usr/lib/GL dir and reestablish/make the syms manually if need be. If unsure how this goes repost. Let us know what you find. HTH, Curtis. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+sJ+f7WVLiDrqeksRAjX9AJ992OyoRRE+NPkyWGXRaw+Ywwg0GQCfb830 dW40ZpAqgb14MiTYfqmTVrc= =rNVA -----END PGP SIGNATURE-----
On Wednesday 30 April 2003 09:16 pm, Curtis Rey wrote:
You may want to look at the monitor settings. I often manually set the monitor params myself or run the x prog that tells you your monitor res timings and cut and past these into the XF86Config file.
I set the monitor more or less manually during installation. All the sync ranges are from the monitor CDROM manual. Which program is that that you refer to?
Also, look at the symlinks for /usr/lib/libGL*.
I don't have a directory by that name on my system.
I am used to dealing with nvidia cards and am unsure about what card your using since I haven't seen the 1st post you made.
It's an Intel 82810 CGC.
I would make sure the the libGL.so is point to LibGL.so.1 and that to the propers GL driver.
This part I don't understand.
Furthermore, you may want to look at /usr/lib/GL so see what other drivers are in there.
In /usr/lib/GL I have two: libGL.so.1.2.xf86 (the one I'm assuming I need) and also libGL.so.1.4.mesasoft.
The symlinks and the drivers are often the issue. If you try to "rpm -e > mesa" or the mesasoft (can't remember exactly but I think it "rpm -e mesasoft") and it complains about the dependencies with the mesa libs (keeping the mesa libs isn't a prob in my experience)
It complains that mesasoft is needed by 3Ddiag.
then you can just manually rm the mesasoft drivers in the /usr/lib/GL dir and reestablish/make the syms manually if need be. If unsure how this goes repost. Let us know what you find.
I appreciate your response, but about 40% of the above is ancient Greek to this home-user Schlub. I'll have to take another look at the monitor settings in YaST and see if I entered the wrong values somewhere. The wierd thing is when I Alt-F2 and try to run a 3D game, the system comes up with a warning that 3D hasn't even been configured yet, even though 3Ddiag and YaST and sax2 all seem to think it has been. I don't know but my two days off are over and I have to work today. Thanks for your attempts to help. -- Bryce Hardy (Santa Rosa, CA) brycehdy@sonic.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Also, look at the symlinks for /usr/lib/libGL*.
I don't have a directory by that name on my system.
Yes you do. You just stated in the following answer that it has both the xf86 glx and mesasoft glx drivers. Don't sweat it, learning the Unix/Linux directory structure take a bit of getting used to, but once you do you'll likely find it easier to find things than in Bills Beast.
I am used to dealing with nvidia cards and am unsure about what card your using since I haven't seen the 1st post you made.
It's an Intel 82810 CGC.
I would make sure the the libGL.so is point to LibGL.so.1 and that to the propers GL driver.
This part I don't understand.
By running the "la" command ( short for list all - as in the all the file parameters). I get this for my nvidia drivers. crrey@Crusher-1:~> la /usr/lib/libGL* lrwxrwxrwx 1 root root 10 2003-04-01 00:38 /usr/lib/libGL.so - -> libGL.so.1 lrwxrwxrwx 1 root root 27 2003-04-01 00:38 /usr/lib/libGL.so.1 -> GL/libGL.so.1.0.4349.nv_glx - -rw-r--r-- 1 root root 4412898 2002-09-10 10:57 /usr/lib/libGLU.a - -rwxr-xr-x 1 root root 780 2002-09-10 10:57 /usr/lib/libGLU.la lrwxrwxrwx 1 root root 13 2003-04-01 18:42 /usr/lib/libGLU.so - -> libGLU.so.1.3 lrwxrwxrwx 1 root root 13 2003-04-01 18:40 /usr/lib/libGLU.so.1 -> libGLU.so.1.3 - -rwxr-xr-x 1 root root 680548 2002-09-10 10:58 /usr/lib/libGLU.so.1.3 lrwxrwxrwx 1 root root 21 2003-04-01 00:38 /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.4349 - -rwxr-xr-x 1 root root 4897592 2003-03-28 03:49 /usr/lib/libGLcore.so.1.0.4349 Symlinks are akin to short cuts, or in this case a pointer for other programs to look for. The symlinks are indicated by the arrows (->). libGL.so points to libGL.so.1 which in turn points to libGL.so.1.0.4349.nv_glx (the nvidia gl driver). Likewise, the libGLU.so does the same. If these are not symlinked correctly, and I suspect this is the case, then a program will look for this and it will either be pointing to the wrong drivers (i.e. mesasoft) or nowhere (yes this can happen - the libGL.so often gets messed up during the install of other drivers this cause it to kludge and then leads nowhare, so programs that look for this and when they try to execute the GL drivers they simply aren't really there - only a symlink. Just like if a shortcut on the desktop didn't know where the program executable was).
Furthermore, you may want to look at /usr/lib/GL so see what other drivers are in there.
In /usr/lib/GL I have two: libGL.so.1.2.xf86 (the one I'm assuming I need) and also libGL.so.1.4.mesasoft.
Go into the /usr/lib/GL and give this command (without qoutes) - "rm measoft*" You could try before this to rpm -e mesasoft (the prm command to remove) but in my experience this will not happen since it is linked to certian libraries and rpm will complain about breaking the dependencies.
The symlinks and the drivers are often the issue. If you try to "rpm -e
mesa" or the mesasoft (can't remember exactly but I think it "rpm -e mesasoft") and it complains about the dependencies with the mesa libs (keeping the mesa libs isn't a prob in my experience)
It complains that mesasoft is needed by 3Ddiag.
Ya, I know it will complain, but is need for supporting older and/or inferior no 3D cards (like an old Stealth 2000 card - that claimed to be 3D back in the mid eighties before the advent of OpenGL and 3Dfx/Voodoo cards were born).
then you can just manually rm the mesasoft drivers in the /usr/lib/GL dir and reestablish/make the syms manually if need be. If unsure how this goes repost. Let us know what you find.
Run the l s /usr/lib/libGL* command and the higlight this with the mouse in the konsole, then middle click once the mouse cursors is on the email page and this will cut and paste this for you (in case your weren't aware of this feature). Repost with the output of the la /usr/lib/libGL* command and I bet well get your hardware 3D running. Cheers, Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+sWmE7WVLiDrqeksRAgQSAJ9kkooZQO1b92S4TFxNATN4HFPKqQCfd3oK rwpCzwmLEnqe/gj0bQHb2rw= =/6uZ -----END PGP SIGNATURE-----
On Thursday 01 May 2003 11:37 am, Curtis Rey wrote:
Repost with the output of the la /usr/lib/libGL* command and I bet well get your hardware 3D running.
OK, here goes: lrwxrwxrwx 1 root root 10 2003-04-28 19:43 /usr/lib/libGL.so -> libGL.so.1 lrwxrwxrwx 1 root root 24 2003-04-28 19:43 /usr/lib/libGL.so.1 -> GL/libGL.so.1.2.xf86_glx lrwxrwxrwx 1 root root 13 2003-04-28 18:24 /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 Thanks for taking the time to help. -- Bryce Hardy (Santa Rosa, CA) brycehdy@sonic.net
participants (2)
-
Bryce Hardy -
Curtis Rey