You are not logged in.
Hi all!
I've been sitting on the nvidia 304xx legacy branch for a while now as it's the only way my valve games will run (examples include left for dead 2, half life 2, and portal), although others run without issue (world of goo, trine 2, spacechem).
Does anyone have any idea why going from packages:
nvidia-304xx
nvidia-304xx-utils
lib32-nvidia-304xx-utilsto
nvidia
nvidia-utils
lib32-nvidia-utils
lib32-nvidia-libglwould stop these games from running? The output I when launching any of the games I mentioned is:
PROBLEM: You appear to have OpenGL 0.0.0, but we need at least 2.0.0!
Could not find required OpenGL entry point 'glGetError'! Either your video card is unsupported, or your OpenGL driver needs to be updated.This error typically comes from not having 32-bit libraries installed, but the installed lib32-nvidia-utils should provide that. Perhaps there is some functionality that the nvidia-304xx packages provide that the latest nvidia packages do not because there is some new package available that I should install?
Any ideas/questions etc appreciated, thanks guys.
Offline
Hi,
did the drivers installed corectly? check with a
glxinfo | grep -i opengland you should see something like:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 9800 GT/PCIe/SSE2
OpenGL core profile version string: 3.3.0 NVIDIA 319.17
OpenGL core profile shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.3.0 NVIDIA 319.17
OpenGL shading language version string: 3.30 NVIDIA via Cg compileralso check if you have nvidia-libgl package beside the lib32-nvidia-libgl.
Last edited by LyCC (2013-05-24 16:11:29)
Offline
I do indeed have nvidia-libgl installed. The output of glxinfo looks fine, I have included the relevant portion below.
% glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4The video card I'm using is an nvidia 9800GT.
Offline
Sorry, i have edited my post meanwhile, please hit a: glxinfo | grep -i opengl
Offline
The output I get from that is:
% glxinfo | grep -i opengl
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 9800 GT/PCIe/SSE2
OpenGL core profile version string: 3.3.0 NVIDIA 319.17
OpenGL core profile shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.3.0 NVIDIA 319.17
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:Offline
Seems we have the same video card, the same drivers installed, driver seems fine, let's try a simple experiment, run
glxgearsjust to see that other applications can access opengl without any problem (since the steam app can't).
If it's run, maybe try to remove the steam package and completly erase ~/.steam folder (even if it seems pointless and unrelated)
(you should back up the installed games, the SteamApps folder if you have a lot of GBs to download again)
also you can check
/sbin/ldconfig -p | grep libGL
and see if files are at the right place, but here you need someone with more knowledge then me to help you.
If all fails, then i'm sorry, but i don't have any more ideas. Maybe report this issue to steam ...
Last edited by LyCC (2013-05-24 18:49:18)
Offline
glxgears runs fine, glxgears32 also runs fine. The output from ldconfig looks sensible to me at least (see below). What makes me suspicious is that no-one else has reported this, there must be other people with the same card on Arch running any of the source engine games. Hrm.
% /sbin/ldconfig -p | grep libGL
libGLU.so.1 (libc6,x86-64) => /usr/lib/libGLU.so.1
libGLU.so.1 (libc6) => /usr/lib32/libGLU.so.1
libGLU.so (libc6,x86-64) => /usr/lib/libGLU.so
libGLU.so (libc6) => /usr/lib32/libGLU.so
libGLEWmx.so.1.9 (libc6,x86-64) => /usr/lib/libGLEWmx.so.1.9
libGLEWmx.so (libc6,x86-64) => /usr/lib/libGLEWmx.so
libGLEW.so.1.9 (libc6,x86-64) => /usr/lib/libGLEW.so.1.9
libGLEW.so.1.9 (libc6) => /usr/lib32/libGLEW.so.1.9
libGLEW.so (libc6,x86-64) => /usr/lib/libGLEW.so
libGLEW.so (libc6) => /usr/lib32/libGLEW.so
libGLESv2.so.2 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGLESv2.so.2
libGLESv2.so.2 (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGLESv2.so.2
libGLESv2.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGLESv2.so
libGLESv2.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGLESv2.so
libGLESv1_CM.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGLESv1_CM.so.1
libGLESv1_CM.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGLESv1_CM.so.1
libGLESv1_CM.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGLESv1_CM.so
libGLESv1_CM.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGLESv1_CM.so
libGL.so.1 (libc6,x86-64) => /usr/lib/libGL.so.1
libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia/libGL.so.1
libGL.so.1 (libc6) => /usr/lib32/libGL.so.1
libGL.so.1 (libc6) => /usr/lib32/nvidia/libGL.so.1
libGL.so (libc6,x86-64) => /usr/lib/libGL.so
libGL.so (libc6,x86-64) => /usr/lib/nvidia/libGL.so
libGL.so (libc6) => /usr/lib32/libGL.so
libGL.so (libc6) => /usr/lib32/nvidia/libGL.soOffline
glxgears runs fine, glxgears32 also runs fine. The output from ldconfig looks sensible to me at least (see below). What makes me suspicious is that no-one else has reported this, there must be other people with the same card on Arch running any of the source engine games. Hrm.
yes, there is one with GF 9800GT that i know of, me
... i just exited from Counter-Strike:Source , it's running fine here ... and we do have the same card, the same drivers, i presume your Arch installation is up to date too, so strange, i guess it must be something trivial that you don't see, it's so strange that steam doesn't see the opengl after a driver change while other apps see it (in this case glxgears), but i don't have any ideas what it could be.
Last edited by LyCC (2013-05-24 20:51:32)
Offline
jpirie,
This is diff between my system and yours:
7a8
> libGLEW.so.1.9 (libc6) => /usr/lib32/libGLEW.so.1.9
9,16c10,18
< libGLESv2.so.2 (libc6,x86-64) => /usr/lib/libGLESv2.so.2
< libGLESv2.so.2 (libc6) => /usr/lib32/libGLESv2.so.2
< libGLESv2.so (libc6,x86-64) => /usr/lib/libGLESv2.so
< libGLESv2.so (libc6) => /usr/lib32/libGLESv2.so
< libGLESv1_CM.so.1 (libc6,x86-64) => /usr/lib/libGLESv1_CM.so.1
< libGLESv1_CM.so.1 (libc6) => /usr/lib32/libGLESv1_CM.so.1
< libGLESv1_CM.so (libc6,x86-64) => /usr/lib/libGLESv1_CM.so
< libGLESv1_CM.so (libc6) => /usr/lib32/libGLESv1_CM.so
---
> libGLEW.so (libc6) => /usr/lib32/libGLEW.so
> libGLESv2.so.2 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGLESv2.so.2
> libGLESv2.so.2 (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGLESv2.so.2
> libGLESv2.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGLESv2.so
> libGLESv2.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGLESv2.so
> libGLESv1_CM.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGLESv1_CM.so.1
> libGLESv1_CM.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGLESv1_CM.so.1
> libGLESv1_CM.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGLESv1_CM.so
> libGLESv1_CM.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGLESv1_CM.so
17a20
> libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia/libGL.so.1
18a22
> libGL.so.1 (libc6) => /usr/lib32/nvidia/libGL.so.1
19a24
> libGL.so (libc6,x86-64) => /usr/lib/nvidia/libGL.so
20a26
> libGL.so (libc6) => /usr/lib32/nvidia/libGL.soWhere did you get all of those funky libraries from? ABI: Linux 2.4.20?
Offline
That 'OS ABI: Linux 2.4.20' is in the output as the 'mesa' and 'lib32-mesa' packages also provide those I see:
mesa /usr/lib/libGLESv1_CM.so
mesa /usr/lib/libGLESv1_CM.so.1
mesa /usr/lib/libGLESv1_CM.so.1.1.0
mesa /usr/lib/libGLESv2.so
.......
lib32-mesa /usr/lib32/libGLESv1_CM.so
lib32-mesa /usr/lib32/libGLESv1_CM.so.1
lib32-mesa /usr/lib32/libGLESv1_CM.so.1.1.0
lib32-mesa /usr/lib32/libGLESv2.so
.......Offline
here's mine:
/sbin/ldconfig -p | grep libGL
libGLU.so.1 (libc6,x86-64) => /usr/lib/libGLU.so.1
libGLU.so.1 (libc6) => /usr/lib32/libGLU.so.1
libGLU.so (libc6,x86-64) => /usr/lib/libGLU.so
libGLU.so (libc6) => /usr/lib32/libGLU.so
libGLEWmx.so.1.9 (libc6,x86-64) => /usr/lib/libGLEWmx.so.1.9
libGLEWmx.so (libc6,x86-64) => /usr/lib/libGLEWmx.so
libGLEW.so.1.9 (libc6,x86-64) => /usr/lib/libGLEW.so.1.9
libGLEW.so.1.9 (libc6) => /usr/lib32/libGLEW.so.1.9
libGLEW.so (libc6,x86-64) => /usr/lib/libGLEW.so
libGLEW.so (libc6) => /usr/lib32/libGLEW.so
libGLESv2.so.2 (libc6,x86-64) => /usr/lib/libGLESv2.so.2
libGLESv2.so.2 (libc6) => /usr/lib32/libGLESv2.so.2
libGLESv2.so (libc6,x86-64) => /usr/lib/libGLESv2.so
libGLESv2.so (libc6) => /usr/lib32/libGLESv2.so
libGLESv1_CM.so.1 (libc6,x86-64) => /usr/lib/libGLESv1_CM.so.1
libGLESv1_CM.so.1 (libc6) => /usr/lib32/libGLESv1_CM.so.1
libGLESv1_CM.so (libc6,x86-64) => /usr/lib/libGLESv1_CM.so
libGLESv1_CM.so (libc6) => /usr/lib32/libGLESv1_CM.so
libGL.so.1 (libc6,x86-64) => /usr/lib/libGL.so.1
libGL.so.1 (libc6) => /usr/lib32/libGL.so.1
libGL.so (libc6,x86-64) => /usr/lib/libGL.so
libGL.so (libc6) => /usr/lib32/libGL.soi don't have any of those 'OS ABI: Linux 2.4.20' despite having mesa and lib32-mesa installed. Other difference i don't see, and like i said, Source engine games are running fine.
Offline
man that is not an upgrade to the drivers, u just changed the proper driver for your device with a driver that does not correspond with your video card, so the solution is to swich back ![]()
Offline
That 'OS ABI: Linux 2.4.20' is in the output as the 'mesa' and 'lib32-mesa' packages also provide those I see
I have both of those packages installed and as you can see above, there is no 'OS ABI: Linux 2.4.20'. Although, I don't run Steam so my presence in this thread may be confusing things.
man that is not an upgrade to the drivers, u just changed the proper driver for your device with a driver that does not correspond with your video card, so the solution is to swich back
The 9800GT is covered by the nvidia and nvidia-utils package. Mine is a 9600GT and is running perfectly.
Last edited by skottish (2013-05-25 02:57:19)
Offline
Dacu wrote:man that is not an upgrade to the drivers, u just changed the proper driver for your device with a driver that does not correspond with your video card, so the solution is to swich back
The 9800GT is covered by the nvidia and nvidia-utils package. Mine is a 9600GT and is running perfectly.
correct, the current nvidia driver covers all cards from GeForce 8xxx up (6xxxx and 7xxxx was dropped in recently)
http://www.nvidia.com/object/linux-disp … river.html (supported products)
and the other drivers he used (version 304.xx) it support the 8xxx series too:
http://www.nvidia.com/object/linux-disp … river.html
so GeForce 9800GT is covered by both drivers, that should not be the problem of games not starting.
But why source engine doesn't see opengl and other apps do (since i have the same card, the same drivers and i have no problem), blows my mind ....
Last edited by LyCC (2013-05-25 07:15:09)
Offline
I think I have found the solution to this (at least a solution for the moment), posting here in case anyone else is googling this problem later. It seems that with the latest version of drivers, (at least on my system?) source games do not play if xinerama is being used. I was able to use xinerama with the old drivers but now it seems it must be disabled for me to launch any source game. Odd, but there we are!
Offline