Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections
anbe at debian.org
Fri Dec 19 11:33:34 UTC 2014
On 2014-12-19 12:01, Ilya Anfimov wrote:
> After investigation, it looks partially true: nvidia_drv.so
> symlink in /usr/lib/xorg/modules/drivers is made by hand, as
but that link alone is not sufficient ...
> update-alternatives --set glx /usr/lib/mesa-diverted
> removes this symlink.
> Hoever, while README states that this configuration is official-
> ly unsupported (which is sad), the bug also could be triggered by
> connecting to the nvidia-driven X-server from machine with mesa
> or ATI libGL drivers.
Can you run the X-server machine with the supported configuration from
update-alternatives --set glx /usr/lib/nvidia
also /usr/lib/xorg/modules/extensions/libglx.so, libnvglx.so are manual
symlinks, get rid of them, too
reinstall xserver-xorg-core to get back the xorg libglx.so
and maybe try a minimal xorg.conf as describd in the README.Debian
>> * some 340.xx driver packages are installed, but that does not support
>> your card, remove them
> OK, I'll try that on fresh debian this weekend (when I could
> boot it from usb flash for experiments).
> However, I think that nvidia-alternative is exactly for keeping
> both versions on one machine.
Correct, but with all the cruft around previously I want to rule out any
potential error source.
> There really was libnvidia-wfb.so* . Removing it and starting X
> server with buggy glx driver doesn't change anything.
> Also, I had attached ls -l on all those directories, just in
> case you'll want to see it.
> + ls -l /usr/lib/xorg/modules/extensions
> -rw-r--r-- 1 root root 2502561 Mar 7 2007 libGLcore.so
> -rw-r--r-- 1 root root 421696 Sep 23 2009 libglx.so-xorg
>> In the end you probably loaded a mix of incompatible versions resulting
>> in your failures.
> Server version is definitely 304.123 -- nvidia driver and nvidia
> glx module are linked to specific libraries, and they scream when
> they are of diffirent versions or when kernel module is different
> version. Attached mmap of X-server, proving that.
please update to 304.125
> Client is Mesa (without any dri installed), it should not take
> any touch of nvidia libraries.
So X is tunneled (via ssh)? This increases the fun ... :-)
Are things working *locally*?
> Also, I've taken some experiments, and found that nvidia
> libGL.so.1 works fine. It works in both direct and indirect mode.
> It also works fine with -340 version of client library (only
> indirect mode, of course).
> Wireshark view of indirect mode traffic shows, that in nvidia
> glx library glXSwapIntervalSGI is made by some NV-GLX extension
> requests, undecoded as there is no NV-GLX decode support in wire-
> shark. I don't know simple ways to disable usage of NV-GLX, so I
> don't know what this client library will do when it will not find
> NV-GLX extension on server.
> ATI's libgl1-fglrx-glx libGL.so.1 library fails, nearly the
> same way as MESA one.
Need to think more about this ...
PS: I'll be mostly offline over the holidays
More information about the pkg-nvidia-devel