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

[Ilya Anfimov]

On Fri, Dec 19, 2014 at 12:33:34PM +0100, Andreas Beckmann wrote:

[skipped]


 I'm  terribly  sorry, I found that in my first letter the method
for reproducing the bug is completely incorrect.
 I found the bug when working with tcl3d, installed  in  /usr/local/
 When  I've  found that debian doesn't have tcl3d, I've tried to use
togl, and I just mistaken it's usage. And it cannot be reproduced
using togl alone.

 The  real step to reproduce is to compile and run swabsgi.c from
my second letter.
 The erroneous output would be:

0_ilan at azor /tmp%./swabsgi
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  48
  Current serial number in output stream:  49
1_ilan at azor /tmp%



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

 I'll  do that tomorrow, but this will not trigger bug locally --
as in all supported configurations, server driver is  always  the
same  as  client libGL.
 Well,  not  exactly impossible, I can dpkg-reconfigure glx after
launching server, but it is not a polite way too.
 However, I'll find remote connection with fresh virtual debian to
confirm the bug.

 [also removed that old and unpackaged files, that you point me in this message]

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

 thanks, reinstalled this also.

[skipped]

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

 Updated, it looks like glx interoperability is broken completely
(BadValue is in X_GLXCreateContext now with Mesa libGL):

0_ilan at azor /tmp%./swabsgi
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  37
  Current serial number in output stream:  38

 Moreover, with 304.125 driver and Mesa libGL --
glxinfo prints the same error.

 However, didn't rebooted yet, just stopped X-server
and replaced nvidia kernel module.




>
> >  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 ... :-)

 Exactly  mine is not -- I am just using mesa client libraries to
be more predictable and traceable, and surely deny direct render-
ing.
 However,  there seems to be misinterpretation of GLX protocol in
nvidia driver, and remote setup will fail even in supported  con-
figuration.

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