* replacing proprietary nvidia driver by nvidia-glx

Posted on October 21st, 2008 by Alex. Filed under Linux.


If the proprietary NVIDIA is installed, it becomes some kind of adventurous, if a new for the Debian distribution kernel is released. Often something new is activated in the stock kernel, so that the kernel module of the NVIDIA driver cannot be compiled resulting in overfilled forums where users ask for solutions.

It is therefore advisable to install a module that comes from Debian, since it will run without any major modifications. In fact even glx and 3D acceleration is supported out of the box without messing up the kernel modules and libraries. Following this guide will lead to a system, where the user benefits from an accelerated 3D desktop system (e.g. for compiz) without leaving the path of Debian’s repositories. This results in a much smoother transition in case of a kernel update.

However the proprietary NVIDIA installer is quite rude regarding the libraries already installed on the system. Since the glx support coming with this driver clashes with mesa, which provides a software emulation of a 3D acceleration for those (though much slower than the hardware solution in the graphics adapter), mesa libraries or links to them are moved out of the way or simply removed. Even if the driver is deinstalled, the previous status before the installation is not or cannot be restored. If nvidia-glx from the Debian repository is installed successfully, the missing links are not repaired and if you check the log files of the xserver, you can find entries like

(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
compiled for 1.4.0.90, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.3

Fortunately this issue can be repaired easily by restoring the proper links to the libraries. If you like to force the xserver to take the right glx libraries by force, you can also remove the packages libgl1-mesa-glx, which will result in many dependency problems (basically the dependency resolution wants to deinstall everything regarding the xserver). The better way is to simply point to the correct libraries:

  1. Login as root.
  2. Go to /usr/lib/xorg/modules/extensions (maybe you have to replace lib by lib64) and check where the link libglx.so points to.
  3. Remove the link and create a new one (with ln) pointing to the nvidia-glx library in the same directory. On my box, the directory reads:
    jitu:/usr/lib/xorg/modules/extensions# ll
    total 1508
    -rw-r--r-- 1 root root 19243 2008-09-30 05:36 libdbe.so
    -rw-r--r-- 1 root root 40804 2008-09-30 05:36 libdri.so
    -rw-r--r-- 1 root root 151818 2008-09-30 05:36 libextmod.so
    lrwxrwxrwx 1 root root 16 2008-10-17 18:14 libglx.so -> libglx.so.177.80
    -rw-r--r-- 1 root root 1246936 2008-10-08 21:54 libglx.so.177.80
    -rw-r--r-- 1 root root 28575 2008-09-30 05:36 librecord.so
    -rw-r--r-- 1 root root 40153 2008-09-30 05:36 libxtrap.so

    As you can see, if have version 177.80 installed.
  4. Change to the directory /usr/lib, where the mess continues.
  5. Check the links to libGLcore.so.1 and libGL.so.1 and repair them similar to the steps above. The links should look like the following lines:
    jitu:/usr/lib# ll libGL*
    lrwxrwxrwx 1 root root 19 2008-10-17 18:14 libGLcore.so.1 libGLcore.so.177.80
    -rw-r--r-- 1 root root 14071292 2008-10-08 21:54 libGLcore.so.177.80
    lrwxrwxrwx 1 root root 15 2008-10-17 18:14 libGL.so.1 -> libGL.so.177.80
    -rw-r--r-- 1 root root 386460 2007-08-28 16:11 libGL.so.1.2.bak
    -rw-r--r-- 1 root root 2480440 2008-07-12 23:02 libGL.so.1.5.070004
    -rw-r--r-- 1 root root 661380 2008-10-08 21:54 libGL.so.177.80
    lrwxrwxrwx 1 root root 20 2008-10-17 15:22 libGLU.so.1 -> libGLU.so.1.3.070004
    -rw-r--r-- 1 root root 532152 2008-09-20 21:19 libGLU.so.1.3.070004

    The right libraries can be easily identified by the version number (177.80). Most probably you also find the libGLcore libraries of mesa in the same directory. However they are not listed in the directory listing above, since I moved them into a backup directory in an attempt to repair my system.
  6. Restart your xserver (Ctrl + Alt + Del) and check /var/log/Xorg.0.log again, if the glx module could be loaded properly. The entry should read:
    (II) LoadModule: "glx"
    (II) Loading /usr/lib/xorg/modules/extensions//libglx.so
    (II) Module glx: vendor="NVIDIA Corporation"
    compiled for 4.0.2, module version = 1.0.0
    Module class: X.Org Server Extension
    (II) NVIDIA GLX Module 177.80 Wed Oct 1 15:06:06 PDT 2008
    (II) Loading extension GLX

Congratulations, if you have completed the above steps successfully. However it does not work (yet), although the correct module is loaded. Do a glxinfo | head in the console and you will see
name of display: :0.0
display: :0 screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 7.0.4
server glx extensions:
GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer
client glx vendor string: Brian Paul

So still the mesa glx libraries are used and using compiz or any other 3D application is not very funny. To solve this problem perform the following steps:

  1. Log in as root again.
  2. cd /usr/lib/i686/cmov
  3. Replace the link pointing to the mesa library by a link that point to the glx library from NVIDIA, which is located two directories below the current one. In my case the directory reads:
    jitu:/usr/lib/i686/cmov# ll
    total 9232
    lrwxrwxrwx 1 root root 21 2008-10-17 15:23 libavcodec.so.51 -> libavcodec.so.51.50.0
    -rw-r--r-- 1 root root 4541100 2008-10-03 20:07 libavcodec.so.51.50.0
    lrwxrwxrwx 1 root root 21 2008-10-17 15:23 libavformat.so.52 -> libavformat.so.52.7.0
    -rw-r--r-- 1 root root 651612 2008-10-03 20:07 libavformat.so.52.7.0
    lrwxrwxrwx 1 root root 19 2008-10-17 15:23 libavutil.so.49 -> libavutil.so.49.6.0
    -rw-r--r-- 1 root root 42884 2008-10-03 20:07 libavutil.so.49.6.0
    -rw-r--r-- 1 root root 1375556 2008-08-04 04:36 libcrypto.so.0.9.8
    lrwxrwxrwx 1 root root 21 2008-10-21 09:59 libGL.so.1 -> ../../libGL.so.177.80
    -rw-r--r-- 1 root root 2468076 2008-07-12 23:02 libGL.so.1.5.070004
    lrwxrwxrwx 1 root root 21 2008-10-17 15:23 libpostproc.so.51 -> libpostproc.so.51.1.0
    -rw-r--r-- 1 root root 46884 2008-10-03 20:07 libpostproc.so.51.1.0
    -rw-r--r-- 1 root root 285156 2008-08-04 04:36 libssl.so.0.9.8
  4. A glxinfo | head should print out the following by now:
    jitu:/usr/lib/i686/cmov# glxinfo | head
    name of display: :0.0
    display: :0 screen: 0
    direct rendering: Yes
    server glx vendor string: NVIDIA Corporation
    server glx version string: 1.4
    server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,
    GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control,
    GLX_EXT_texture_from_pixmap, GLX_ARB_multisample, GLX_NV_float_buffer,
    GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB

    and glxgears to check out the correct installation should print out
    jitu:/usr/lib/i686/cmov# glxgears
    19293 frames in 5.0 seconds = 3858.536 FPS
    19420 frames in 5.0 seconds = 3883.991 FPS

    instead of
    5466 frames in 5.0 seconds = 1093.091 FPS (on a NVIDIA GT8600M)



Trackback URI | Comments RSS

Leave a Reply


RSS Feeds:

Search:


Pages:

Categories:

Archives: