search

jMonkeyEngine / jmonkeyengine

A complete 3-D game development suite written in Java.
http://jmonkeyengine.org
BSD 3-Clause "New" or "Revised" License
3.84k stars 1.13k forks source link

Lwjgl-3.3.0 GLFW cannot create a GL window on armhf #1710

Closed pavly-gerges closed 2 years ago

pavly-gerges commented 2 years ago

I have tested jme3-lwjgl3 dependency with :

1) Lwjgl-3.3.0 GLFW and natives, the GLFW cannot create the GL window : 

pi@raspberrypi:~/NativeJmeTemplate/output/run $ ./run.sh 
Run
..................................
Dec 09, 2021 12:44:14 PM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.5.0-alpha1
 * Branch: HEAD
 * Git Hash: dc91668
 * Build Date: 2021-11-14
Dec 09, 2021 12:44:16 PM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: LWJGL 3.3.0 build 21 context running on thread jME3 Main
 * Graphics Adapter: GLFW 3.4.0 Wayland X11 GLX Null EGL OSMesa monotonic shared
Dec 09, 2021 12:44:16 PM com.jme3.renderer.opengl.GLRenderer loadCapabilitiesCommon
INFO: OpenGL Renderer Information
 * Vendor: Broadcom
 * Renderer: V3D 4.2
 * OpenGL Version: 2.1 Mesa 19.3.2
 * GLSL Version: 1.20
 * Profile: Compatibility
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.ogre.MeshLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.ogre.SkeletonLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.ogre.MaterialLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.ogre.SceneLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.fbx.FbxLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.gltf.GltfLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.gltf.BinLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.gltf.GlbLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.audio.plugins.OGGLoader
Dec 09, 2021 12:44:16 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.NullPointerException
    at org.lwjgl.system.Callback.get(Callback.java:190)
    at org.lwjgl.glfw.GLFWWindowSizeCallback.create(GLFWWindowSizeCallback.java:36)
    at org.lwjgl.glfw.GLFWWindowSizeCallback.createSafe(GLFWWindowSizeCallback.java:45)
    at org.lwjgl.glfw.GLFW.glfwSetWindowSizeCallback(GLFW.java:3139)
    at com.jme3.input.lwjgl.GlfwMouseInput.initCallbacks(GlfwMouseInput.java:243)
    at com.jme3.input.lwjgl.GlfwMouseInput.initialize(GlfwMouseInput.java:184)
    at com.jme3.app.LegacyApplication.initInput(LegacyApplication.java:337)
    at com.jme3.app.LegacyApplication.initialize(LegacyApplication.java:640)
    at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:198)
    at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:524)
    at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:640)
    at com.jme3.system.lwjgl.LwjglWindow.create(LwjglWindow.java:477)
    at com.jme3.app.LegacyApplication.start(LegacyApplication.java:491)
    at com.jme3.app.LegacyApplication.start(LegacyApplication.java:443)
    at com.jme3.app.SimpleApplication.start(SimpleApplication.java:126)
    at test.TestJni.main(TestJni.java:18)

Dec 09, 2021 12:44:16 PM com.jme3.app.LegacyApplication handleError
SEVERE: Failed to destroy context
java.lang.NullPointerException
    at org.lwjgl.system.Callback.get(Callback.java:190)
    at org.lwjgl.glfw.GLFWErrorCallback.create(GLFWErrorCallback.java:40)
    at org.lwjgl.glfw.GLFWErrorCallback.createSafe(GLFWErrorCallback.java:49)
    at org.lwjgl.glfw.GLFW.glfwSetErrorCallback(GLFW.java:1288)
    at com.jme3.system.lwjgl.LwjglWindow.destroyContext(LwjglWindow.java:436)
    at com.jme3.system.lwjgl.LwjglWindow.deinitInThread(LwjglWindow.java:624)
    at com.jme3.system.lwjgl.LwjglWindow.lambda$initInThread$12(LwjglWindow.java:494)
    at java.base/java.lang.Thread.dispatchUncaughtException(Thread.java:2002)

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Resource id in failed request:  0x1a00061
  Serial number of failed request:  1818
  Current serial number in output stream:  1818

Seems that GLFW cannot find the graphics adapter :

INFO: LWJGL 3.3.0 build 21 context running on thread jME3 Main

I believe that this is a lwjgl issue, but we are expecting its from jme until proved otherwise.

2) Lwjgl-3.2.3 GLFW and natives, the app works fine with a non null graphics adapter :

image

Sorry i am not on the pi now to copy this stack trace, but this is the important finding.

forum thread : https://hub.jmonkeyengine.org/t/jme3-5-0-alpha-on-armhf/45207/2?u=pavl_g

stephengold commented 2 years ago

Switching between LWJGL 3.2.3 and 3.3.0 requires more than just the right natives. It also involves a small change to "LWJGLOpenVR.java". I think the entire JME 3.5 release should use a single version of LWJGL.

So far, I haven't seen any advantage of LWJGL 3.3.0 over 3.2.3, so returning to 3.2.3 might be our best path.

pavly-gerges commented 2 years ago

I don't know about LWJGLOpenVR.java, for me I just removed the 3.3.0 jar dependencies and added all the 3.2.3 jar dependencies including the native dependencies for both the amd64 and arm32 linux.

EDIT : the right path might be looking onto lwjgl-3.3.0 and lwjgl-3.2.3 release notes and compare them, if there are really no benefits for jme then rolling back to lwjgl-3.2.3 would be the best solution, if there are benefits for jme then pi-users have to add lwjgl-3.2.3 manually and exclude lwjgl-3.3.0 and we should document that inside jme3.5.0 release notes !

Ali-RS commented 2 years ago

I added a commit on my fork that may fix your issue: https://github.com/Ali-RS/jmonkeyengine/commit/5dc3e27d388da9290e967185874920386e6465e0

can you give it a try, please?

tonihele commented 2 years ago

I added a commit on my fork that may fix your issue

I doubt it fixes the problem. I hope I'm wrong of course. But this is very good fix nevertheless. Could also cause a memory leak since the MouseInput hijacked the callback but actually never even bothered to close it like the Window tried to. Good stuff!

Ali-RS commented 2 years ago

Thanks

stephengold commented 2 years ago

@Scrappers-glitch: does this issue still occur in JME v3.5.1-stable?

pavly-gerges commented 2 years ago

@Scrappers-glitch: does this issue still occur in JME v3.5.1-stable?

I haven't tried with jme3.5.1-stable (still using jme3.5.0-alpha), but last week i have tested with removed lwjgl-3.3.0 dependencies and it works fine (with lwjgl-3.2.3).

This is the working update : https://github.com/Scrappers-glitch/NativePiTemplate/tree/master/code/java/dependencies

So far i am not using gradle on this project, so i have my dependencies downloaded from lwjgl official.

If you have changed the default lwjgl3 to be lwjgl3.2.3, then i am expecting the error to be resolved, but let me know if we want to test on gradle.

stephengold commented 2 years ago

For the JMonkeyEngine v3.5.1-stable release, the only question was whether to move forward to LWJGL v3.3.1 or stick with LWJGL v3.3.0 . We never considered going back to LWJGL v3.2.3 .

Since you're sure the issue is with LWJGL, then I'd like to know whether LWJGL v3.3.1 works for armhf. Would you be willing to test armhf with a version of LWJGL other than v3.2.3?

pavly-gerges commented 2 years ago

Yes, I will try to prepare a testcase for lwjgl-3.3.1 by the next week.

stephengold commented 2 years ago

@Scrappers-glitch I gather from the Forum that this issue was caused by a build mixup. Shall I close this as "invalid"?

pavly-gerges commented 2 years ago

@Scrappers-glitch I gather from the Forum that this issue was caused by a build mixup. Shall I close this as "invalid"?

The issue is persistent with lwjgl-3.3.0, but it has been resolved on lwjgl-3.3.1, so I tested lwjgl-3.3.1 on the forum and it works fine, now to fix this issue, a PR migrating to lwjgl-3.3.1 should be committed to close this issue 🙂.

stephengold commented 2 years ago

Since "master" branch is already on lwjgl-3.3.1, I'm closing this issue.

stephengold commented 2 years ago

Now that I have RPi hardware, I'm seeing a similar issue with current "master" branch JMonkeyEngine (which uses lwjgl-3.3.1): GLFW fails to create a window. However, the stack trace is different than the one reported above:

Apr 13, 2022 11:23:15 PM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.6.0-SNAPSHOT
 * Branch: master
 * Git Hash: 3d979df
 * Build Date: 2022-04-13
Apr 13, 2022 11:23:16 PM com.jme3.app.LegacyApplication handleError
SEVERE: GLX: Failed to create context: GLXBadFBConfig
java.lang.Exception: GLX: Failed to create context: GLXBadFBConfig
    at com.jme3.system.lwjgl.LwjglWindow$1.invoke(LwjglWindow.java:229)
    at org.lwjgl.glfw.GLFWErrorCallbackI.callback(GLFWErrorCallbackI.java:43)
    at org.lwjgl.system.JNI.invokePPPP(Native Method)
    at org.lwjgl.glfw.GLFW.nglfwCreateWindow(GLFW.java:2024)
    at org.lwjgl.glfw.GLFW.glfwCreateWindow(GLFW.java:2197)
    at com.jme3.system.lwjgl.LwjglWindow.createContext(LwjglWindow.java:294)
    at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:582)
    at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:704)
    at java.base/java.lang.Thread.run(Thread.java:834)

Apr 13, 2022 11:23:16 PM com.jme3.app.LegacyApplication handleError
SEVERE: Failed to create display
java.lang.RuntimeException: Failed to create the GLFW window
    at com.jme3.system.lwjgl.LwjglWindow.createContext(LwjglWindow.java:296)
    at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:582)
    at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:704)
    at java.base/java.lang.Thread.run(Thread.java:834)

Apr 13, 2022 11:23:16 PM com.jme3.system.lwjgl.LwjglWindow run
SEVERE: Display initialization failed. Cannot continue.
pavly-gerges commented 2 years ago

Interesting, but isn't that a different exception, I mean this takes place at jme creating the context from openGL, while the original exception is due to Glfw window ?! And also this exception didn't info out the lwjgl-3 version and the state of glfw window ? It only says SEVERE : GLX which I anticipate it as a openGL dependency problem.

You may check other lwjgl-3 dependencies and ensure all are 3.3.1.

stephengold commented 2 years ago

You're right that this is a different exception, at a different point in the initialization process. I'm continuing to investigate. If this goes much deeper, I'll file a new issue and close this one.

stephengold commented 2 years ago

The root cause of the GLXBadFBConfig crash was that the RPi doesn't support OpenGL 3.2 . Back in January, PR #1752 made 3.2 the default.

The workaround was to set the renderer to "LWJGL-OpenGL2" in main(). With that workaround, I was able to run TestJaime, both with LWJGL 3.2.3 and LWJGL 3.3.1 . I was also able to reproduce the original NPE (in Callback.java line 190) using LWJGL 3.3.0 .

Closing this issue.

pavly-gerges commented 2 years ago

The workaround was to set the renderer to "LWJGL-OpenGL2" in main().

The raspberry pi supports upto GLES 3.1 and GL2 for desktop, as raspbian doesn't use OGLES, so should we set opengl to 2 by default for linux arm desktops ?

stephengold commented 2 years ago

should we set opengl to 2

That's way outside my area of expertise, so I leave that to others to decide.

The issue is persistent with lwjgl-3.3.0, but it has been resolved on lwjgl-3.3.1

Based on your testing, it's clear we can solve the "Callback.java" NPE in the v3.5 branch by simply backporting https://github.com/jMonkeyEngine/jmonkeyengine/commit/ae750c0696c561774ea8271d521b9bc40a2be0ee (upgrading LWJGL to v3.3.1). My own tests confirm this.

The NPE was a regression relative to JME 3.4.1. Therefore, we should backport the fix ASAP and publish a JME 3.5.2 release. I'll start the process.