Lwjgl3: Screen won't render anything (LWJGL 3.0.0 build 90)

Created on 24 Jun 2016  路  12Comments  路  Source: LWJGL/lwjgl3

With LWJGL 3.0.0 build 90 my Laptop won't render anything on my Linux system (sample program).
All I get is the window with the stuff rendered in it which was behind it when creating the window. Key input is working though.
On Windows 7 (same Laptop) and also on my Linux PC (with AMD R9 390 and Crimson driver) it works like expected.

May be related with those Forum Threads:
http://forum.lwjgl.org/index.php?topic=6251.0
http://forum.lwjgl.org/index.php?topic=6255.0

glxinfo | grep OpenGL:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Mobile Intel庐 GM45 Express Chipset 
OpenGL version string: 2.1 Mesa 10.1.3
OpenGL shading language version string: 1.20

LWJGL debug info:

[LWJGL] Version: 3.0.0 build 90
[LWJGL]      OS: Linux v3.19.0-32-generic
[LWJGL]     JRE: 1.8.0_91 amd64
[LWJGL]     JVM: OpenJDK 64-Bit Server VM v25.91-b14 by Oracle Corporation
[LWJGL] Loading library (system): lwjgl
[LWJGL]     Loaded from org.lwjgl.librarypath: native/liblwjgl.so
[LWJGL] ThreadLocalUtil state: UnsafeState
[LWJGL] MemoryUtil accessor: MemoryAccessorUnsafe
[LWJGL] Loading library: glfw
[LWJGL]     Loaded from org.lwjgl.librarypath: native/libglfw.so
libEGL warning: failed to create a pipe screen for i965
[LWJGL] Loading library: libGL.so.1
[LWJGL]     libGL.so.1 not found in org.lwjgl.librarypath=native/
[LWJGL]     libGL.so.1 not found in java.library.path=/usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib
[LWJGL]     Loaded from system paths
Bug 3rd party

Most helpful comment

This is quite possibly resolved in GLFW master.

All 12 comments

Sounds like the same issue indeed. To verify:

a) Run glxgears. Does it work?
b) Build GLFW locally and try out its demos. Do they have the same problem?

If the answers are "yes" and "yes":

  • Report this to GLFW.
  • (much more helpful) If you've got the time, try commits newer than 3.1.2 but older than 3.2, until you find the commit that's responsible for the issue. Since there are a ton of commits since 3.1.2, you can limit testing to commits that affected glx_context.c or x11_window.c.

a) Run glxgears. Does it work?

glxgears works like expected.

b) Build GLFW locally and try out its demos. Do they have the same problem?

The examples work for 3.1.2, but with 3.2 it has the same issue.

I will test some of the commits since 3.1.2 and will report back if I find the commit which caused it.

Looked through some commits and it seems like the issue exists since GLFW/glfw@ef80bea.

Same here, everything works fine with 3.0.0b build 35 but not with build 90 (checked on Windows and OS X). Has this been reported to GLFW?

You can compile GLFW yourself with commit glfw/glfw@9d50a34 and put it in your natives folder/jar until this bug is fixed.

Looking into this.

Hi guys, any news?

@dannycalleri Not yet. Working on it.

This is quite possibly resolved in GLFW master.

Thanks @elmindreda!

LWJGL users: the current nightly build contains the latest GLFW master changes. Note that it's a "modular" build. If you haven't used one before, you'll have adjust your build process accordingly.

@elmindreda
With the current master the issue is resolved. Tested it just now.

So this technically isn't fixed yet; I just made it much harder to hit. Until I've fixed it properly, it may still happen if people play with the GLFW_CONTEXT_CREATION_API hint on the X11 backend.

In the meantime, I'll put out a 3.2.1 to give everyone this workaround (and a few unrelated fixes).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Zamundaaa picture Zamundaaa  路  4Comments

hoijui picture hoijui  路  7Comments

ShadowLordAlpha picture ShadowLordAlpha  路  3Comments

knokko picture knokko  路  4Comments

ChrisTrenkamp picture ChrisTrenkamp  路  6Comments