I installed the newly released Mesa-6.2 and it seems to work with that now.
Borlan
Wayne Boucher wrote:
>Hello,
>
>After a bit of grief (just finding an SGI with a compiler on it) I can see
>what is causing the problem but the "solution" so far is not complete.
>
>In order to know what "drawable" (OpenGL jargon) is being drawn in, the
>Python widget gets passed to the C world and a "context" (more OpenGL
>jargon) is created, and to do that you need a "visual" (more OpenGL
>jargon). Then when you want to draw into that drawable you make a call to
>glXMakeCurrent() with that drawable and context as arguments. The
>glXMakeCurrent() man page says:
>
>"BadMatch is generated if drawable was not created with the same X screen
>and visual as ctx. It is also generated if drawable is None and ctx is not
>None."
>
>I checked explicitly and drawable and ctx (the context) are both not None.
>And there is only one screen. So it looks like the drawable was not
>created with the same visual as ctx. Like I said, the drawable comes from
>the Python world and which visual it is created with is a bit beyond our
>control. The visual in the C world is created as follows (this is in the
>function new_gl_handler() in ccpnmr1.0/c/ccpnmr/global/gl_handler.c):
>
> visual = glXChooseVisual(display, DefaultScreen(display), dblBuf);
>
>where dblBuf is defined a bit above that line as:
>
> static int dblBuf[] = {GLX_RGBA, GLX_DOUBLEBUFFER, None};
>
>The first two arguments mean:
>
> GLX_RGBA: If present, only TrueColor and DirectColor visuals are
>considered. Otherwise, only PseudoColor and StaticColor visuals are
>considered.
>
> GLX_DOUBLEBUFFER: If present, only double-buffered visuals are
>considered. Otherwise, only single-buffered visuals are considered.
>
>If I use dblBuf as is, or if I remove either but not both of those
>arguments, then I get the BadMatch problem. I am not too bothered about
>GLX_RGBA but I am about GLX_DOUBLEBUFFER. If I remove both, so have:
>
> static int dblBuf[] = {None};
>
>then I do not get the BadMatch problem. So I end up being able to display
>contours. Only the whole thing does not really work properly: the
>background is black instead of white, the crosshair does not get
>refreshed (so the xor mode is not working), etc. (This is probably
>because the Python code pretty much assumes double buffering is working.)
>So this is not sorted yet.
>
>Is there double buffering on these oldish SGIs? I thought there was, but
>perhaps not.
>
>Wayne
>
>On Tue, 26 Oct 2004, Borlan Pan wrote:
>
>
>
>>Unfortunately, neither GL_FALSE and GL_TRUE help.
>>
>>Borlan
>>
>>Wayne Boucher wrote:
>>
>>
>>
>>>Hello,
>>>
>>>I've done a bit of a trawl on google and as usual the question appears a
>>>few times but not the answer. In particular already back in 1999 someone
>>>had this problem with exactly the same note about it working on another
>>>display:
>>>
>>>http://oss.sgi.com/projects/performer/mail/info-performer/perf-99-08/0000.html
>>>
>>>Someone in 2002 also had this kind problem trying to use another display
>>>(so even worse than you are having, but the "X Error of failed request"
>>>was different):
>>>
>>>http://oss.sgi.com/projects/performer/mail/info-performer/perf-02-01/0004.html
>>>
>>>and said they had tried xhost to sort this out but it did not.
>>>
>>>Now recently we changed one of the parameters in one of the first OpenGL
>>>calls because it was causing the non-drawing of contours on Linux boxes
>>>using native Nvidia OpenGL drivers. You could try changing this back to
>>>see what happens. So in ccpnmr1.0/c/ccpnmr/global/gl_handler.c in the
>>>function new_gl_handler() there is a line:
>>>
>>> context = glXCreateContext(display, visual, None, GL_FALSE);
>>>
>>>and you could change this back to:
>>>
>>> context = glXCreateContext(display, visual, None, GL_TRUE);
>>>
>>>(it's commented out in the text above the current version). Then type
>>>"make" and "cd ../analysis" and "make" and try running Analysis again.
>>>
>>>If that works then we can try to put both variants in (somehow). (My
>>>guess is that it will not solve it but you never know.)
>>>
>>>Wayne
>>>
>>>
>>>
>>>
