I can't reproduce your results. It still fails in exactly the same way for me with or without the patch, and whether or not I'm displaying to an X server that has the NV-GLX extension. Local, remote, VNC, whatever. Still fails.
The driver can't be enabling NV-GLX, because why would it print the warning otherwise? It seems to be trying to enable NV-GLX but failing to do so. Thus, how could removing the NV-GLX extension from the X extension list affect the way the driver is behaving? That extension isn't being enabled anyhow. This also does not explain why the problem just started appearing in WINE 1.3.11. If it's truly an nVidia bug, you would think it would appear elsewhere as well. > I tested this hypothesis and it seems correct. > > Don't apply attached patch, and run with DISPLAY and VGL_DISPLAY as :0 > with NVIDIA 260 driver: > fails with VendorPrivate error. > > Apply attached path, and run with DISPLAY and VGL_DISPLAY as :0 with > NVIDIA 260 driver: > debris demo works. > > Apply attached patch, and run with DISPLAY=remote X.org + 185 driver > and VGL_DISPLAY as :0 on 260 driver: > fails with invalid Render command (obviously NVIDIA tries to fall > back to unofficial GLX when NV-GLX isn't present if the Vendor is > NVIDIA, even when the AllowUnofficialGLX flag is off). > > Apply attached patch, and run with DISPLAY=Exceed with ATI driver : > it gets so far as to draw the window and start the progress bar, but > then fails with: > X Error of failed request: GLXUnsupportedPrivateRequest > Major opcode of failed request: 136 (GLX) > Minor opcode of failed request: 16 (X_GLXVendorPrivate) > Serial number of failed request: 1639 > Current serial number in output stream: 1640 > (This error returned by Exceed). > > The vop is 1416, which Exceed doesn't claim to support via extensions, > and I don't know anything about (googling turns up empty). > > The only thing I didn't test was a remove NVIDIA 260 driver with NV-GLX > disabled (because I want to keep my other 185 driver), but given making > DISPLAY and VGL_DISPLAY = :0 reproduced the same VendorPrivate error and > disabling NV-GLX fixed it I think it should work. > > Conclusion is NVIDIA does bad things in its driver with unknown protocol > and it seems that's pretty difficult for VGL to work around. > > > -Nathan > > ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
