GLFW under Wayland problem

Started by Aisaaax, October 29, 2020, 04:52:44

Previous topic - Next topic

Aisaaax

Hello. I have a system that supports only wayland (there's no x11 graphics drivers at all), and I know that GLFW should have no problems working unter it.
But when I run the jar on that system - it still attempts to go through X11 - Xwayland. And that simply doesn't work (we tried).
I've downloaded the latest LWJGL build and confirmed that all wayland-native .so files are present for GLFW. But it still chooses to attempt to go through X11 versions.

Is there some kind of variable that I'm missing?

spasi

Hey, yes, you need to set Configuration.GLFW_LIBRARY_NAME (or the "org.lwjgl.glfw.libname" system property) to "libglfw_wayland.so".

Aisaaax

Yeah, I did that, but for some reason it just crashes on the very first GLFW call. Like, it doesn't even throw or catch exceptions - just immediately goes to execute the "Finally" block.
very weird.

Aisaaax

I'm using GLFW jars that come with LWJGL.

Tried running the program with this key:
-Dorg.lwjgl.glfw.libname=libglfw_wayland.so
Also tried doing that in code:
Configuration.GLFW_LIBRARY_NAME.set("libglfw_wayland.so");

But it does not compile, because it doesn't have some functions/symbols available:
Window init() started
[LWJGL] Loading library: libglfw_wayland.so
[LWJGL] 	Module: org.lwjgl.glfw
[LWJGL] 	Loaded from org.lwjgl.librarypath: /tmp/lwjgl<myusername>/3.2.4-build-6/libglfw_wayland.so
/home/<myusername>/bin/jdk1.8.0_231/bin/java: symbol lookup error: /tmp/lwjgl<myusername>/3.2.4-build-6/libglfw_wayland.so: undefined symbol: __wrap_memcpy


So I thought OK. I found the needed symbol and compiled the .so containing it from sources. Then added it to LD_PRELOAD
LD_PRELOAD=./libwrap_memcpy.so

It kinda runs, but there are several bugs. For one thing, the window is undecorated, even if I specify the GLFW window hint as Decorated=true
For another, the rendering frame is for some reason smaller than the window. It's clearly proportional to that, but smaller (see attachment).
You can also notice that despite me not specifying any position, the window is created with some offset from the upper-left corner of the screen, which seems a bit weird.
https://ibb.co/VqvkGT8

Finally, it gives out a couple of errors into Debug log, which for now don't seem to prevent anything from working, but are still worrysome:
Window init() started
[LWJGL] GLFW_FEATURE_UNAVAILABLE error
	Description : Wayland: The platform does not support setting the input focus
	Stacktrace  :
		org.lwjgl.glfw.GLFW.nglfwCreateWindow(GLFW.java:1884)
		org.lwjgl.glfw.GLFW.glfwCreateWindow(GLFW.java:2059)
		view3d.Window.Init_GLFW(Window.java:257)
		view3d.Engine.init(Engine.java:59)
		view3d.Engine.run(Engine.java:37)
		java.lang.Thread.run(Thread.java:748)
[LWJGL] Loading library: libEGL.so.1
[LWJGL] 	Module: org.lwjgl.egl
[LWJGL] 	libEGL.so.1 not found in org.lwjgl.librarypath=/tmp/lwjgl<myusername>/3.2.4-build-6
[LWJGL] 	Loaded from system paths: /lib/x86_64-linux-gnu/libEGL.so.1
[LWJGL] Loading JNI library: lwjgl_opengles
[LWJGL] 	Module: org.lwjgl.opengles
[LWJGL] 	Loaded from org.lwjgl.librarypath: /tmp/lwjgl<myusername>/3.2.4-build-6/liblwjgl_opengles.so
[LWJGL] Loading library: libGLESv2.so.2
[LWJGL] 	Module: org.lwjgl.opengles
[LWJGL] 	libGLESv2.so.2 not found in org.lwjgl.librarypath=/tmp/lwjgl<myusername>/3.2.4-build-6
[LWJGL] 	Loaded from system paths: /lib/x86_64-linux-gnu/libGLESv2.so.2
Window handle created 140244037407328
EGL DisplayHandle 140244037251008
EGL caps created
Current context: 3.2 rev 0, Client_Context: 196610
CLES caps created
Current context: 3.2
[LWJGL] GLFW_FEATURE_UNAVAILABLE error
	Description : Wayland: The platform does not support setting the input focus
	Stacktrace  :
		org.lwjgl.glfw.GLFW.glfwShowWindow(GLFW.java:2694)
		view3d.Window.Init_GLFW(Window.java:293)
		view3d.Engine.init(Engine.java:59)
		view3d.Engine.run(Engine.java:37)
		java.lang.Thread.run(Thread.java:748)


Any pointers on how to solve all that?
I also gotta say that if I don't specify any library, it still works through wayland on my PC - and it creates a good decorated window and posts no errors.
But on the ARM device it tries to go through X11 -> XWayland, and because there's no X11 hardware support on that device it causes an exception in wayland compositor. So I HAVE TO tell it specifically to use wayland libs.

I'm not sure if it's an LWJGL problem, but I suspect that it's at least partially so because of the symbol lookup errors that suggest that your build might not include something critical.

spasi

Hey Aisaaax,

The missing symbol is indeed a bug in LWJGL's Wayland build. It will be fixed in the next nightly. Thanks!

Missing window decorations is expected on Wayland, since it doesn't support decorations natively. For this and other issues related to Wayland, please see GLFW's issues. Afaict, there's quite a bit of activity on Wayland support.