Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections

[Andreas Beckmann]

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.

More cruft:

> + 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 ...

Andreas

PS: I'll be mostly offline over the holidays