f20 :: nvidia direct rendering :: ok for root, not ok for user

[Adrian Sevcenco]

On 01/06/2014 01:09 PM, Adrian Sevcenco wrote:
> Hi! I have a strange (strange because it is working for root) situation
> with nvidia direct rendering ..
> 
> for user:
> adrian at hal : ~ $ glxinfo
> name of display: :0
> libGL error: failed to load driver: swrast
> libGL error: Try again with LIBGL_DEBUG=verbose for more details.
> Error: couldn't find RGB GLX visual or fbconfig
> Error: couldn't find RGB GLX visual or fbconfig
> 
> adrian at hal : ~ $ LIBGL_DEBUG=verbose glxinfo
> name of display: :0
> libGL: screen 0 does not appear to be DRI2 capable
> libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
> libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
> libGL error: failed to load driver: swrast
> Error: couldn't find RGB GLX visual or fbconfig
> Error: couldn't find RGB GLX visual or fbconfig
> 
> adrian at hal : ~ $ ls -la /usr/lib64/dri/swrast_dri.so
> -rwxr-xr-x. 1 root root 5926488 Dec 20 21:26 /usr/lib64/dri/swrast_dri.so
> 
> 
> for root:
> adrian at hal : ~ $ sudo glxinfo
> name of display: :0
> display: :0  screen: 0
> direct rendering: Yes
> server glx vendor string: NVIDIA Corporation
> server glx version string: 1.4
> 
> Have anyone any idea about the problem? what should the user have access
> to or set up?

one more thing i found out:

root at hal: ~ # ldd /bin/glxgears
        linux-vdso.so.1 =>  (0x00007fff573ee000)
        libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x0000003440600000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003ee0e00000)
        libX11.so.6 => /lib64/libX11.so.6 (0x0000003ee3600000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003ee1200000)
        libnvidia-tls.so.331.20 =>
/usr/lib64/nvidia/tls/libnvidia-tls.so.331.20 (0x000000343d800000)
        libnvidia-glcore.so.331.20 =>
/usr/lib64/nvidia/libnvidia-glcore.so.331.20 (0x000000343dc00000)
        libXext.so.6 => /lib64/libXext.so.6 (0x0000003ee4a00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003ee1600000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x0000003ee3200000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003ee0a00000)
        libXau.so.6 => /lib64/libXau.so.6 (0x0000003ee3a00000)



adrian at hal : ~ $ ldd /bin/glxgears
        linux-vdso.so.1 =>  (0x00007fffe334f000)
        libGL.so.1 => /lib64/libGL.so.1 (0x0000003eef200000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003ee0e00000)
        libX11.so.6 => /lib64/libX11.so.6 (0x0000003ee3600000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003ee1200000)
        libglapi.so.0 => /lib64/libglapi.so.0 (0x0000003eefa00000)
        libXext.so.6 => /lib64/libXext.so.6 (0x0000003ee4a00000)
        libXdamage.so.1 => /lib64/libXdamage.so.1 (0x0000003ef0200000)
        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x0000003ee6e00000)
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x0000003eeda00000)
        libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x0000003eefe00000)
        libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x0000003ef0600000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x0000003ee3200000)
        libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x0000003eee200000)
        libdrm.so.2 => /lib64/libdrm.so.2 (0x0000003eee600000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ee1a00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003ee1600000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003ee4200000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003ee0a00000)
        libXau.so.6 => /lib64/libXau.so.6 (0x0000003ee3a00000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003ee3e00000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x0000003ee2e00000)


So ... why the difference?
Thank you!
Adrian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140106/c2ef4573/attachment.p7s>