Glfw 2.7 trunk

cleanrock wrote on Tuesday, June 23, 2009:

I tried the trunk glfw today and get the following immediate crash :

bifrost:~/glfw/trunk/examples$ ./gears
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 135 (GLX)
Minor opcode of failed request: 24 (X_GLXCreateNewContext)
Value in failed request: 0x0
Serial number of failed request: 0
Current serial number in output stream: 20

Any idea what might be wrong ?

I am running archlinux and my GL apps that use the dist glfw (2.6) works fine.

elmindreda wrote on Tuesday, June 23, 2009:

Hmm, not sure. What did you pass to OpenWindow and OpenWindowHint?

cleanrock wrote on Tuesday, June 23, 2009:

well, i am running your gears test app my post but i get the same error when i run my own apps which are fine with glfw 2.6

elmindreda wrote on Tuesday, June 23, 2009:

Oh, silly me. I don’t have a clue right now, but I’ll look into it.

cleanrock wrote on Monday, June 29, 2009:

it wasnt that hard to find :

2.7 uses glXCreateNewContext (GLX>=1.3) and 2.6 uses glXCreateContext.

glXCreateNewContext call should be :
_glfwWin.context = glXCreateNewContext( _glfwLibrary.display, _glfwWin.fbconfig, GLX_RGBA_TYPE, NULL, True );
Perhaps GLX_RGBA_TYPE has been 0 before but it is 32788 on my platform.

From spec (http://www.opengl.org/sdk/docs/man/xhtml/glXCreateNewContext.xml) :

render_type
Specifies the type of the context to be created. Must be one of
GLX_RGBA_TYPE or GLX_COLOR_INDEX_TYPE.

elmindreda wrote on Monday, June 29, 2009:

Oops. I had fixed it in lite but not in trunk. Thank you!

cleanrock wrote on Monday, June 29, 2009:

aha, so perhaps i should go for 2.7-lite if i shall use 2.7 ?
i.e. is 2.7-lite more up to date and the version u aim to mainly develop/support ?

elmindreda wrote on Monday, June 29, 2009:

Well, no, at this point I try to keep trunk and lite in sync every time I make an edit. I originally created lite to be my personal sandbox, but then GLSDK came along and needed something very much like it, so now I consider them to be equally important. I’d say that lite is better unless you need threading, but mostly due to dalfy’s CMake work.

They’re also not binary compatible, due to a calling convention change.

Once 3.0 is released, lite and the current trunk will both be obsoleted. If anyone wants an API similar to the current lite after that, it’ll be trivial to implement on top of 3.0.