On 3/1/11 3:02 PM, Nathan Kidd wrote:
This matches what my WireShark trace saw (last request was
glXCreatePBuffer). In that hypothesis:
VGL handles glXCreatePbuffer() with no problems (I even test for that in
rrfakerut.) In the trace, that function completes without error, so it
must be a
On 11-03-02 03:01 AM, DRC wrote:
On 3/1/11 3:02 PM, Nathan Kidd wrote:
This matches what my WireShark trace saw (last request was
glXCreatePBuffer). In that hypothesis:
VGL handles glXCreatePbuffer() with no problems (I even test for that in
rrfakerut.) In the trace, that function
On 11-03-01 04:02 PM, Nathan Kidd wrote:
Hmmm, actually, I have an idea, based on what DRC said before about
NV-GLX. When an NV-GLX libGL talks to a server that supports NV-GLX it
has additional traffic (major opcode 139 on my server). This must be
where the error comes from and why nothing
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
Bingo.
Apparently nVidia is trying to outsmart us yet again and is somehow
making a determination in the underlying GLX library that it needs to
send glXSwapIntervalSGI() over the wire rather than to the display on
which the GLX context has been established (bad, bad nVidia! Bad! No
treat for
On 2/28/11 10:57 AM, Nathan Kidd wrote:
Right, there's no way for us to know the application's intention for
querying for the visual or what internal logic it does afterward.
Would you be ok to move it to a trace-only message? If such an app ever
did exist and we were trying to track down
