BadMatch with glXMakeCurrent

  • Permalink
  • submit to reddit
  • Email
  • Follow


I am trying to get pbuffers working with glX.  The pbuffer
appears to be created correctly (lots of asserts never fail
and glXQueryGLXPbufferSGIX reports the correct sizes).
When I call glXMakeCurrent the first time with the pbuffer's
display, drawable, and context, I get

  X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  144 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  33
  Current serial number in output stream:  33

The man pages on glXMakeCurrent say that BadMatch is generated
if the drawable was not created with the same X screen and visual
as the context (or if the drawable is None and context is NULL, neither
condition occuring in my code).

I am trying to share a context, so
  Display* dpy = glXGetCurrentDisplay();
  int scr = DefaultScreen(dpy);
  GLXContext ctx = glXGetCurrentContext();
  int cfgCount;
  GLXFBConfig* cfg = glXGetFBConfigs(dpy,scr,&cfgCount);  // cfgCount is 48, 
cfg not null
  int attr[] = { GLX_LARGEST_PBUFFER, 1, 0 };
  GLXPbuffer pbuf = glXCreateGLXPbufferSGIX(dpy,cfg[0],width,height,attr); 
// pbuf not null
  // glXQueryGLXPbufferSGIX calls indicate success so far...
  glXMakeCurrent(dpy,pbuf,ctx);  // fails here with BadMatch

Any clues what the problem is?

--
Dave Eberly
http://www.geometrictools.com



0
Reply Dave 5/17/2005 7:11:36 PM

See related articles to this posting


Dave Eberly wrote:
> I am trying to get pbuffers working with glX.  The pbuffer
> appears to be created correctly (lots of asserts never fail
> and glXQueryGLXPbufferSGIX reports the correct sizes).
> When I call glXMakeCurrent the first time with the pbuffer's
> display, drawable, and context, I get
> 
>   X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  144 (GLX)
>   Minor opcode of failed request:  5 (X_GLXMakeCurrent)
>   Serial number of failed request:  33
>   Current serial number in output stream:  33
> 
> The man pages on glXMakeCurrent say that BadMatch is generated
> if the drawable was not created with the same X screen and visual
> as the context (or if the drawable is None and context is NULL, neither
> condition occuring in my code).
> 
> I am trying to share a context, so
>   Display* dpy = glXGetCurrentDisplay();
>   int scr = DefaultScreen(dpy);
>   GLXContext ctx = glXGetCurrentContext();
>   int cfgCount;
>   GLXFBConfig* cfg = glXGetFBConfigs(dpy,scr,&cfgCount);  // cfgCount is 48, 
> cfg not null
>   int attr[] = { GLX_LARGEST_PBUFFER, 1, 0 };
>   GLXPbuffer pbuf = glXCreateGLXPbufferSGIX(dpy,cfg[0],width,height,attr); 
> // pbuf not null
>   // glXQueryGLXPbufferSGIX calls indicate success so far...
>   glXMakeCurrent(dpy,pbuf,ctx);  // fails here with BadMatch
> 
> Any clues what the problem is?

Assuming that ctx is not NULL, then there is the question of whether the 
context was created using the same FBConfig that was used to create the 
Pbuffer (assuming the glXCreateNewContext was used to create the 
context).  If the context was created by glXCreateContext, then you will 
need to make sure that the FBConfig that you use to create the Pbuffer 
is associated with the visual used to create the context (FBConfigs do 
not have to be associated with an X visual id).  Since the 
glXChooseFBConfig subroutine won't use the GLX_VISUAL_ID token, you will 
have to loop through the list of FBConfigs that you received from 
glXGetFBConfigs and use the glXGetFBConfigAttrib subroutine to get the 
visual id associated with each FBConfig (if one exists) to find one that 
matches the visual id used to create the context.   Once you find that 
FBConfig, then you use it to create your Pbuffer and, hopefully, your 
BadMatch will go away.

Jim Lahue
0
Reply Jim 5/18/2005 12:42:05 PM

"Jim Lahue" <jmlahue@us.NO_SPAM.ibm.com> wrote in message 
news:3f0rlhF5c0e5U1@individual.net...

Thank you for taking the time to post help!

> Assuming that ctx is not NULL, then there is the question of whether the 
> context was created using the same FBConfig that was used to create the 
> Pbuffer (assuming the glXCreateNewContext was used to create the context). 
> If the context was created by glXCreateContext, then you will need to make 
> sure that the FBConfig that you use to create the Pbuffer is associated 
> with the visual used to create the context (FBConfigs do not have to be 
> associated with an X visual id).  Since the glXChooseFBConfig subroutine 
> won't use the GLX_VISUAL_ID token, you will have to loop through the list 
> of FBConfigs that you received from glXGetFBConfigs and use the 
> glXGetFBConfigAttrib subroutine to get the visual id associated with each 
> FBConfig (if one exists) to find one that matches the visual id used to 
> create the context.   Once you find that FBConfig, then you use it to 
> create your Pbuffer and, hopefully, your BadMatch will go away.

The original context was created by glXCreateContext.  I managed
to figure out how glXGetFBConfigAttrib works and looped through
the array of FBConfigs and found one whose visual ID matches that of
my "main" renderer.  The match occurred for a FBConfig that was
not the zero-th index of the array.  (I was using nVidia's pbuffer code
sample as a guide--they just grab the zero-th index FBConfig.)  The
BadMatch went away.

Unfortunately, my test application is still not working correctly after
this change.  I render the mesh to the pbuffer, copy it to a system
memory chunk, and then create a texture. The texture is attached to
a screen polygon.  (Still waiting on that graphics-hardware-agnostic
render-to-texture support on Linux.)  The mesh is rendered to the
backbuffer, and then the screen polygon is rendered to the
backbuffer, followed by the usual swap.  On my Windows machine,
I see the mesh in the center of the main window (gray background)
and the screen polygon with this same mesh in a corner of the main
window (white background).  On the Linux box, the screen polygon
shows up with a white background, but no mesh.  This is using
glXGetFBConfigs, glXGetFBConfigAttrib, glXCreateNewContext,
and glXCreatePbuffer to set up the pbuffer.

If I create the pbuffer instead using glXChooseFBConfigSGIX,
glXCreateContextWithConfigSGIX, and glXCreateGLXPbufferSGIX,
the screen polygon shows up correctly.

Additional hints are welcome.  Thanks.

--
Dave Eberly
http://www.geometrictools.com


0
Reply Dave 5/18/2005 4:28:38 PM

Dave Eberly wrote:
<snip snip snip>
> 
> The original context was created by glXCreateContext.  I managed
> to figure out how glXGetFBConfigAttrib works and looped through
> the array of FBConfigs and found one whose visual ID matches that of
> my "main" renderer.  The match occurred for a FBConfig that was
> not the zero-th index of the array.  (I was using nVidia's pbuffer code
> sample as a guide--they just grab the zero-th index FBConfig.)  The
> BadMatch went away.
> 
> Unfortunately, my test application is still not working correctly after
> this change.  I render the mesh to the pbuffer, copy it to a system
> memory chunk, and then create a texture. The texture is attached to
> a screen polygon.  (Still waiting on that graphics-hardware-agnostic
> render-to-texture support on Linux.)  The mesh is rendered to the
> backbuffer, and then the screen polygon is rendered to the
> backbuffer, followed by the usual swap.  On my Windows machine,
> I see the mesh in the center of the main window (gray background)
> and the screen polygon with this same mesh in a corner of the main
> window (white background).  On the Linux box, the screen polygon
> shows up with a white background, but no mesh.  This is using
> glXGetFBConfigs, glXGetFBConfigAttrib, glXCreateNewContext,
> and glXCreatePbuffer to set up the pbuffer.
> 
> If I create the pbuffer instead using glXChooseFBConfigSGIX,
> glXCreateContextWithConfigSGIX, and glXCreateGLXPbufferSGIX,
> the screen polygon shows up correctly.
> 
> Additional hints are welcome.  Thanks.

Well, did you try using glXChooseFBConfig with the same attribute list 
as you used in glXChooseFBConfigSGIX?  I'm not entirely sure that the 
two accept exactly the same tokens (I think that the GLX 1.3 version is 
a bit more strict in what it allows).   The search methodology used by 
glXChooseFBConfig and glXChooseFBConfigSGIX do differ slightly but both 
of them will probably be different from the 
glXGetFBConfigs/glXGetFBConfigAttrib search method.

My guess is that you ended up using two different FBConfigs based on the 
two different search methods:  one of the FBConfigs worked for you and 
the other didn't.  This is just a guess, though.   I can't think of any 
other reason why using the SGI versions of the subroutines should give 
you different results from the GLX 1.3 versions of the subroutines.

Jim Lahue
0
Reply Jim 5/19/2005 1:34:07 PM

"Jim Lahue" <jmlahue@us.NO_SPAM.ibm.com> wrote in message 
news:3f3j33F5qp4sU1@individual.net...

> Well, did you try using glXChooseFBConfig with the same attribute list as 
> you used in glXChooseFBConfigSGIX?

I am not using glXChooseFBConfig.  The two cases are (1) create
a pbuffer using the framebuffer's pixel format (via glXGetFBConfig)
and (2) create a pbuffer using a specified attribute list (via
glxChooseFBConfigSGIX).  A similar dichotomy is used on Windows.
A stripped down version of the functions acts as pseudocode (error
handling removed, for example).
http://www.geometrictools.com/Temp/pbuffer.txt
The WGL code works for either (1) or (2).  The GLX code only
works for (2).  As mentioned (1) leads to a white background (so I
know the clear call for a white background colors is working), but
no mesh.

Thanks again for your comments.  I only have to go through this
yet one more time--now on the Macintosh.  Apple has some
pbuffer extensions that appear to be documented.  I can only cross
my fingers and hope to see some working examples...

--
Dave Eberly
http://www.geometrictools.com


0
Reply Dave 5/19/2005 6:16:10 PM

Dave Eberly wrote:
> "Jim Lahue" <jmlahue@us.NO_SPAM.ibm.com> wrote in message 
> news:3f3j33F5qp4sU1@individual.net...
> 
> 
>>Well, did you try using glXChooseFBConfig with the same attribute list as 
>>you used in glXChooseFBConfigSGIX?
> 
> 
> I am not using glXChooseFBConfig.  The two cases are (1) create
> a pbuffer using the framebuffer's pixel format (via glXGetFBConfig)
> and (2) create a pbuffer using a specified attribute list (via
> glxChooseFBConfigSGIX).  A similar dichotomy is used on Windows.
> A stripped down version of the functions acts as pseudocode (error
> handling removed, for example).
> http://www.geometrictools.com/Temp/pbuffer.txt
> The WGL code works for either (1) or (2).  The GLX code only
> works for (2).  As mentioned (1) leads to a white background (so I
> know the clear call for a white background colors is working), but
> no mesh.
> 
> Thanks again for your comments.  I only have to go through this
> yet one more time--now on the Macintosh.  Apple has some
> pbuffer extensions that appear to be documented.  I can only cross
> my fingers and hope to see some working examples...

It would seem that your results depend quite a bit on the type (and/or 
number) of FBConfigs that exist on the system -- maybe it works on the 
WGL system because it only supports a few FBConfigs and so you end up 
with the same one no matter which method you use.   You may want to 
write a short program that displays the resources available with each 
FBConfig on the failing system and then see which FBConfig that your 
program chooses in the good and bad cases and see what the differences are.

Jim Lahue
0
Reply Jim 5/20/2005 3:34:25 PM

"Jim Lahue" <jmlahue@us.NO_SPAM.ibm.com> wrote in message 
news:3f6egqF67oqrU1@individual.net...
> It would seem that your results depend quite a bit on the type (and/or 
> number) of FBConfigs that exist on the system -- maybe it works on the WGL 
> system because it only supports a few FBConfigs and so you end up with the 
> same one no matter which method you use.   You may want to write a short 
> program that displays the resources available with each FBConfig on the 
> failing system and then see which FBConfig that your program chooses in 
> the good and bad cases and see what the differences are.

Thanks for the suggestion.  I had printed out the FBConfig results
on the Linux box--48 possibilities.  Only one matched the visual
ID for the framebuffer associated with my application window.
From what I understand of your earlier post, that is the only one
I can use without getting a BadMatch.

Well, the SGIX version works for now and I'll just live with that.
At the rate graphics hardware/extensions are evolving for "buffer"
objects, hopefully the interfaces and usage will become simpler.
After all these years of OpenGL, you would think that there would
be some official wrapper/API to hide having to deal with the
platform-dependent calls for the more advance features....

--
Dave Eberly
http://www.geometrictools.com


0
Reply Dave 5/20/2005 3:55:16 PM
comp.graphics.api.opengl 7092 articles. 24 followers. Post

6 Replies
303 Views

Similar Articles

[PageSpeed] 49


  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

glXMakeCurrent crash..?
I have a multithreaded application which draws glX objects to screen. I use glXMakeCurrent() before I start painting. But when I run my application, after about ~30 redraws, the program crashes with an X error: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 128 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 70 Current serial number in output stream: 70 What exactly causes this? Grz, The Doctor The Doctor wrote: > I have a multithreaded applicati...

Threading and glXMakeCurrent/XCloseDisplay
Hi, I recently ran into a problem with multiple threads accessing Xlib and GLX functions, causing a segmentation fault error. First of: Yes every Xlib/GLX call is properly synchronized meaning at every time only one thread is running in an Xlib/GLX function. So please don't come up with comments about thread synchronization. I outline the thread interaction briefly: MainThread AnotherThread XOpenDisplay() glXMakeCurrent() - using connection opened by AnotherThread XCloseDisplay() ...

glXMakeCurrent & XMapWindow
Hi guys I just copied-pasted some code that I found on the net to create a XWindow & I also compared it with the code which is given the OpenGl/XWindow green book. Basically the code compiled fine but the widnow would be displayed to the screen. I tried 2 things, adding a XFlush call which actually causes the window to be displayed but I also swapped the positions of glXMakeCurrent & XMapWindow and then the window got displayed too... So I am too sure why the example that I found on the next call glXMakeContext first and XMapWindow second and still probably managed somehow t...

glXMakeCurrent fails
Hi all, I have a little problem. I'm writing an opengl plugin for mozilla. the mozilla browser feeds me with a Drawable m_Window ("Window" datastructure). I have no influence how this Window is created. Basically I perform the following steps to get the GL Context: pVisInfo = glXChooseVisual(m_pDisplay,DefaultScreen(m_pDisplay),GLCapabilities); m_pDefVisInfo = XGetVisualInfo(m_pDisplay, VisualScreenMask, m_pVisInfo, &i); m_GLContext = glXCreateContext(m_pDisplay, m_pDefVisInfo, None, TRUE); At a later stage I call ... glXMakeCurrent(m_pDisplay, m_Window, m_GLContext); ...

Gdk-ERROR **: BadMatch (invalid parameter attributes)
We have an application compiled to 64bit on Solaris platform. In this application we use gdk pixbuf to show our graphics. Somehow sometimes during the first time to show the graphics, the application crashes and gave us the following error msgs: Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 81056 error_code 8 request_code 73 minor_code 0 The strange thing is that it only crashes occasionally. Can someone help to point out how to resolve this issue? It could be related to memory issues. Is there any good reference disscussing how GTK and GDK handles memory? Thanks a lo...

Mac Lion Update Produces BadMatch Error
Folks, I've been contacted by several people who have recently updated to Max OSX 10.7.2 (Lion) and are having problems with Coyote Graphics routines. Thanks to an e-mail from David Brockley this morning, who finally figured out what the problem is and how to work around it. The error looks something like this: IDL> cgPlot, IndGen(10) % Compiled module: CGSNAPSHOT. % X windows protocol error: BadMatch (invalid parameter attributes). % X windows protocol error: BadMatch (invalid parameter attributes). % X windows protocol error: BadMatch (invalid parameter attributes). The problem a...

Some insights: wxGTK, OpenGL and BadMatch X errors
Hello all, I too have been affected by "BadMatch" X errors when using wxGLCanvas under wxGTK, and did, as promised in an earlier thread, some research. First, despite the BadMatch errors, I'm now convinced that the implementation of wxGLCanvas in wxGTK 2.6.x is correct. Although I think that Rick Schnells observations in http://groups.google.de/group/comp.soft-sys.wxwindows/browse_thread/thread/18b28d21655aee80/637d8f17685dcff5 are very interesting and correct too in their fine points, I've also found that the wxGLApp class is not needed under (Debian) Linux...

X11 over ssh on Fedora Core 5 BadMatch
Hi, I am rather irregular X user who has used X11 over ssh on Fedora Core 4 to perform remote admin tasks on the linux box. I am in the process of setting up a new box with Fedora Core 5 to replace this, but having problems with subject. Basically I can pull up an xterm wihtout any difficulty, but whenever I select a more complex app, it appears mometarily on the client machine then bombs out on the ssh terminal session complaining of a BadMatch attributes etc.. Any direction of where to start looking very welcome. Many Thanks ...

Virtual machine errors: badmatch, badwindow, object graphics
In IDL 6.0 for Mac OS-X, X11 I am working on a program, surfview.pro, from the Intermediat IDL booklet. It is one of the object graphics programs. It works fine in idlde. So as an extra exercise, I decided to try to convert it to a ..sav file for use with the virtual machine. I did the system reset, compiled it again, RESOLVE_ALL and then SAVE. Everything copacetic. So I run idl -vm from my X11 and it comes up with the old BadWindows error, viz. -- 11:16am% idl -vm=/Applications/idl_6.0/surfview.sav [IDL version etc.] % Restored file: IDLVMMAIN. % X windows protocol error: BadMatch (i...

Gdk-ERROR **: BadMatch (invalid parameter attributes) related with gdkpixbuf
We have an application compiled to 64bit on Solaris platform. In this application we use gdk pixbuf to show our graphics. Somehow sometimes during the first time to show the graphics, the application crashes and gave us the following error msgs: Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 81056 error_code 8 request_code 73 minor_code 0 The strange thing is that it only crashes occasionally. Can someone help to point out how to resolve this issue? It could be related to memory issues. Is there any good reference disscussing how GTK and GDK handles memory? Thanks a lo...

X Error of failed request: BadMatch (invalid parameter attributes)
Here's my linux error message: = this is the startup message i.e. before any problems > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 42 (X_SetInputFocus) = those 2 lines would tell an 'X expert' what's wrong ? > Serial number of failed request: 343415 > Current serial number in output stream: 343416 > When I run an app. [linux-ETHZ-Oberon] in a desktop of kde-3, which is inet-fetching [mail or news or http] and which would write the contents to screen, but can't write to screen, ...

wxGTK2.6.2: XError 'BadMatch' in wxGrid::DrawCell
I'am lost how to debug this one. I hope anybody has an idea how to = proceed. My program exits with this message: The program 'wxt' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 13238 error_code 8 request_code 70 minor_code 0) (Note to programmers: normally, X errors are reported = asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line ...

[Wine] X Error of failed request: BadMatch (invalid parameter attributes)
I have compiled wine 0.9.17 with the wine-wow patch. I start up WoW with double buffering enabled and WoW fails. I disable double buffering in winecfg and wine starts, but the screen flickers as a result of disabling double buffering. I am using an nvidia 6600gt graphics card, amd athlon 3000 cpu with 1GB of ram. I am running Fedora Core 5. I am using the latest and greatest driver from NVIDIA. I am using hardware opengl. I receive the following error: fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONTEXT_VALUE; STUB X Error of failed request: BadMatch (invalid pa...

New Twist on %BadMatch (invalid parameter attributes) error in IDL module for ENVI
Hi all, I'm running ENVI+IDL 4.8 on Lion with a set of IDL code located in ENVI's s= ave_add directory. My IDL code uses the CG routines for displays and statu= s windows that are outside of ENVI's domain. While my progress bar window= s are updating, the BadMatch errors are being thrown in the IDL window. Af= ter several hundred of these errors, the entire workbench/ENVI crashes in a= glorious fashion. I've followed David's article: http://www.idlcoyote.com/misc_tips/badmatch.php, and included 'Device, Retain=3D2; in my IDL startup file (didn't work) and =...