View Issue Details

IDProjectCategoryView StatusLast Update
0000714channel: elrepo/el7kmod-nvidiapublic2017-09-10 07:59
Reporterjchan Assigned Topperry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Summary0000714: glxgears
Descriptionrunning glxgears using the 375.26 driver in an xterm or in RealVNC causes glxgears to crash with this message.

Error: couldn't get an RGB, Double-buffered visual

However, I don't have this issue on the 367.57 driver, or if I install the 375 driver directly from NVIDIA.
TagsNo tags attached.
Attached Files
libGLX_indirect.diff (2,983 bytes)   
diff --git a/nvidia-x11-drv/el6/nvidia-x11-drv.spec b/nvidia-x11-drv/el6/nvidia-x11-drv.spec
index c81dabc..2158905 100644
--- a/nvidia-x11-drv/el6/nvidia-x11-drv.spec
+++ b/nvidia-x11-drv/el6/nvidia-x11-drv.spec
@@ -261,9 +261,6 @@ pushd nvidiapkg
 %{__ln_s} libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so.1
 %{__ln_s} libGLX.so.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGLX.so
 %{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libGLX_nvidia.so.0
-%{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libGLX_indirect.so.0
-# Fixes bug http://elrepo.org/bugs/view.php?id=714
-%{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{_libdir}/libGLX_indirect.so.0
 # Added libnvcuvid.so in 260.xx series driver
 %{__ln_s} libnvcuvid.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libnvcuvid.so
 %{__ln_s} libnvcuvid.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libnvcuvid.so.1
@@ -309,9 +306,6 @@ pushd nvidiapkg
 %{__ln_s} libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialib32dir}/libGL.so.1
 %{__ln_s} libGLX.so.0 $RPM_BUILD_ROOT%{nvidialib32dir}/libGLX.so
 %{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libGLX_nvidia.so.0
-%{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libGLX_indirect.so.0
-# Fixes bug http://elrepo.org/bugs/view.php?id=714
-%{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{_prefix}/lib/libGLX_indirect.so.0
 %{__ln_s} libnvcuvid.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libnvcuvid.so
 %{__ln_s} libnvcuvid.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libnvcuvid.so.1
 %{__ln_s} libnvidia-encode.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libnvidia-encode.so
@@ -389,6 +383,11 @@ echo %{nvidialib32dir} >> $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/nvidia.conf
 echo %{_prefix}/lib/vdpau >> $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/nvidia.conf
 %endif
 
+# Install scriptlets to set GLX vendor name
+%{__mkdir_p} $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/
+echo "export __GLX_VENDOR_LIBRARY_NAME=nvidia" > $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/nvidia.sh
+echo "setenv __GLX_VENDOR_LIBRARY_NAME nvidia" > $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/nvidia.csh
+
 popd
 
 %clean
@@ -476,6 +475,7 @@ fi ||:
 %config(noreplace) %{_sysconfdir}/modprobe.d/nvidia.conf
 %config %{_sysconfdir}/ld.so.conf.d/nvidia.conf
 %config %{_sysconfdir}/udev/makedev.d/60-nvidia.nodes
+%config %{_sysconfdir}/profile.d/nvidia.*sh
 %{_sysconfdir}/OpenCL/vendors/nvidia.icd
 %{_sysconfdir}/vulkan/icd.d/nvidia_icd.json
 
@@ -485,7 +485,6 @@ fi ||:
 %{nvidialibdir}/alternate-install*
 %dir %{nvidialibdir}/tls
 %{nvidialibdir}/tls/lib*
-%{_libdir}/libGLX_indirect.so.0
 %{_libdir}/vdpau/libvdpau_nvidia.*
 %{_libdir}/xorg/modules/drivers/nvidia_drv.so
 %dir %{_libdir}/xorg/modules/extensions/nvidia
@@ -499,7 +498,6 @@ fi ||:
 %{nvidialib32dir}/lib*
 %dir %{nvidialib32dir}/tls
 %{nvidialib32dir}/tls/lib*
-%{_prefix}/lib/libGLX_indirect.so.0
 %{_prefix}/lib/vdpau/libvdpau_nvidia.*
 %endif
 
libGLX_indirect.diff (2,983 bytes)   
Reported upstream

Relationships

duplicate of 0000713 resolvedpperry Error: Could't get an RGB. Double-buffered Visual 

Activities

pperry

2017-01-27 22:41

administrator   ~0005056

The only major change I'm aware of between 367.xx and 375.xx is that we now enable GLVND by default, but nvidia were already doing this so unless you were running non-GLVND libs on your test install directly from nvidia, it doesn't explain the difference in behaviour between our package(s) and installing direct from nvidia.

If you can figure out what's changed / broken, I'll be happy to fix if it's an issue in our packaging of the driver.

pperry

2017-01-27 23:08

administrator   ~0005057

Duplicate of http://elrepo.org/bugs/view.php?id=713

pperry

2017-01-28 00:27

administrator   ~0005058

In order to help better understand the issue and potentially fix it, I'm trying to replicate the issue.

Are you just opening an xterm window locally on an el7 install and running glxgears? If so, I am unable to replicate this behaviour.

I don't have VNC or any remote connections to my test box to be able to replicate.

jchan

2017-01-30 11:25

reporter   ~0005059

Thants for the repsonse!

Its when I run a xTerm on my local machine (XQuartz on OSX or Mobaxterm on Windows) and ssh into a remote el7 host and run glxgears. I have yet to try this on a Linux laptop, but I'm pretty sure I'll get the same result.

osmiza

2017-05-19 06:48

reporter   ~0005213

Hi at all,
same problem here, on an el6 installation. I've solved with a simlink to /usr/lib64/nvidia/libGLX_indirect.so.0 in /usr/lib64

  ln -s /usr/lib64/nvidia/libGLX_indirect.so.0 /usr/lib64/libGLX_indirect.so.0

there are a lot of people around with the same problem (search on google for 'nvidia libGLX_indirect.so.0'). Probably the problem is related to the new GLVND support of NVIDIA driver (but I'm not sure).

Some references here:

https://devtalk.nvidia.com/default/topic/915640/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/
https://bugs.freedesktop.org/show_bug.cgi?id=99987#c7
https://bugzilla.redhat.com/show_bug.cgi?id=1413579#57

pperry

2017-05-19 12:49

administrator   ~0005214

Thanks for the suggested fix. If others could confirm it fixes the issue?

I can queue the fix for the next release and users can apply the fix manually for now.

jchan

2017-06-02 15:57

reporter   ~0005247

Hi!

Thank you for the follow up! it looks like adding in the softlinks to libGLX fixed the issue for me!

-Jed

pperry

2017-06-02 16:18

administrator   ~0005248

Thanks for confirming Jed.

The fix will be in the next package release, as you have a workaround for now.

pperry

2017-07-27 15:17

administrator   ~0005349

Packages for version 384.59 have just been released and contain osmiza's fix so should fix this issue.

If someone could confirm these updated packages now fix the issue, that would be great.

Thanks

rg

2017-08-13 15:39

developer   ~0005386

This symlink thing is a bad hack. After ldconfig is run, you get this in /usr/lib[64]:

libGLX_indirect.so.0 -> nvidia/libGLX_indirect.so.0
libGLX_nvidia.so.0 -> libGLX_indirect.so.0

The first link is the "fix" from the updated package, the second link is created by ldconfig because the SONAME of libGLX_indirect.so.0 is in fact libGLX_nvidia.so.0. Now we get a second entry /usr/lib64/libGLX_nvidia.so.0 in /etc/ld.so.cache in addition to /usr/lib64/nvidia/libGLX_nvidia.so.0. On the other hand, /usr/lib64/libGLX_indirect.so.0 still gets no entry in /etc/ld.so.cache because that's not the SONAME of any library. If only works because in the end, ld.so will manually go through /usr/lib[64], something it doesn't do for usr/lib[64]/nvidia.

A clean solution would be to remove _all_ libGLX_indirect.so.0 links and export __GLX_VENDOR_LIBRARY_NAME=nvidia instead.

pperry

2017-08-13 15:51

administrator   ~0005387

@rg,

Thanks for the analysis. Would you be able to submit a patch, either here or as a pull request on github: https://github.com/elrepo/packages

As an aside, I have been considering a switch in approach, and instead of installing all the nvidia libs to /usr/lib[64]/nvidia/, just install everything to /usr/lib[64], apart from libGL.so.1 which conflicts with libGL.so.1 from the mesa-libGL distro package and would still need to be installed elsewhere.

This would presumably resolve this issue, plus I don't think this is the first time we've run into problems with some libs in /usr/lib[64]/nvidia/ not being found.

Any thoughts?

pperry

2017-08-13 16:32

administrator   ~0005388

Similar issue reported on Fedora here:

https://bugzilla.redhat.com/show_bug.cgi?id=1427174

From that bug, Hans de Goede writes in comment 31:

"Libglvnd relies on a GLX extension to tell it which vendor library to use, and if the server doesn't support that extension (which I'm assuming it doesn't), then it'll try to load a vendor library named libGLX_indirect.so.0 instead. The reason for that is so that indirect rendering can still work when you connect to a remote X server.

libGLX_indirect.so.0 should just be a symlink to another vendor. For indirect rendering, any vendor will do, since they should all speak the same GLX protocol.

But, if libGLX_indirect.so.0 doesn't exist, then libglvnd won't be able to find any vendor library to load, so it won't be able to handle any GLX calls at all."

Later in the same post he suggests linking libGLX_indirect.so.0 to the mesa lib on the basis any vendor lib will do for indirect GLX:

sudo ln -s /usr/lib64/libGLX_mesa.so.0 /usr/lib64/libGLX_indirect.so.0

and then proposes to add that symlink to the mesa package in Fedora, a change that has been made in Fedora 25

To avoid conflict, rpmfusion now symlink against mesa in fedora 25 and above, and nvidia in earlier releases:

# GlVND
%if 0%{?fedora} >= 25
# We keep the same symlink than mesa-libGL to avoid conflict
ln -s %{_libdir}/libGLX_mesa.so.0 %{buildroot}%{_libdir}/libGLX_indirect.so.0
%else
ln -s libGLX_nvidia.so.%{version} %{buildroot}%{_libdir}/libGLX_indirect.so.0
# ld.so.conf.d file
install -m 0755 -d %{buildroot}%{_sysconfdir}/ld.so.conf.d/
echo -e "%{_nvidia_libdir} \n" > %{buildroot}%{_sysconfdir}/ld.so.conf.d/nvidia-%{_lib}.conf
%endif


I assume at some point this change will filter through into the mesa package in RHEL at which point we may have to handle it similarly.

rg

2017-08-13 17:39

developer   ~0005390

The fallback is either via the libGLX_indirect.so.0 link or the __GLX_VENDOR_LIBRARY_NAME environment variable. I propose to use the latter approach for ElRepo for the reasons mentioned above. Patch attached.

pperry

2017-08-14 00:16

administrator   ~0005391

Given that at some point in the future, upstream is likely to symlink libGLX_indirect.so.0 against mesa, I'm inclined to agree exporting __GLX_VENDOR_LIBRARY_NAME is a cleaner solution.

I'll queue for inclusion in the next release.

pperry

2017-09-10 07:59

administrator   ~0005472

I've reverted the original fix in 384.59-1 and applied the fix to export _GLX_VENDOR_LIBRARY_NAME in 384.69-2

Packages should be built and released later today.

Closing as fixed. Please reopen / refile if further issues.

Thanks to all

Issue History

Date Modified Username Field Change
2017-01-27 16:54 jchan New Issue
2017-01-27 16:54 jchan Status new => assigned
2017-01-27 16:54 jchan Assigned To => pperry
2017-01-27 22:41 pperry Note Added: 0005056
2017-01-27 22:43 pperry Relationship added duplicate of 0000713
2017-01-27 23:09 pperry Note Added: 0005057
2017-01-28 00:27 pperry Note Added: 0005058
2017-01-30 11:25 jchan Note Added: 0005059
2017-05-19 06:48 osmiza Note Added: 0005213
2017-05-19 12:49 pperry Note Added: 0005214
2017-06-02 15:57 jchan Note Added: 0005247
2017-06-02 16:18 pperry Note Added: 0005248
2017-07-27 15:17 pperry Note Added: 0005349
2017-07-27 15:18 pperry Status assigned => resolved
2017-07-27 15:18 pperry Resolution open => fixed
2017-07-27 15:21 pperry Status resolved => assigned
2017-08-13 15:39 rg Note Added: 0005386
2017-08-13 15:51 pperry Note Added: 0005387
2017-08-13 16:32 pperry Note Added: 0005388
2017-08-13 17:14 rg File Added: libGLX_indirect.diff
2017-08-13 17:39 rg Note Added: 0005390
2017-08-14 00:16 pperry Note Added: 0005391
2017-09-10 07:59 pperry Note Added: 0005472
2017-09-10 07:59 pperry Status assigned => resolved