Tristan Daniel

It's hard to determine on which side changes should be made. On one hand, Minecraft treats all messages from GLFW as fatal errors. But on the other hand, the flag GLFW_PLATFORM_ERROR used for unimplemented methods in GLFW is the same as the one used for actual fatal errors such as window creation failures, so Minecraft can't make the difference between legitimate fatal errors and unimplemented methods.

Ideally, GLFW would add a new flag used by unimplemented methods, and Minecraft could filter errors and silently ignore those, hoping their absence won't break anything. And later on, when GLFW implements them and stops throwing errors, Minecraft won't have to do anything and things will Just Work™.

Since LWJGL 3.1.4, it is possible to tell LWJGL to use the Wayland backend by launching the game with "-Dorg.lwjgl.glfw.libname=glfw_wayland". Doing this results in a crash that seems to be caused by GLFW.

However, using a version of GLFW newer than the one bundled in LWJGL 3.1.6 seems to fix the problem. I'm on Arch Linux and the package glfw-wayland currently provides GLFW 3.3 compiled with Wayland support. Launching the game with "-Dorg.lwjgl.glfw.libname=/usr/lib/libglfw.so" gets me past the first problem. But this time, the game crashes with GLFW complaining that "Focusing a window requires user interaction". Wayland does indeed not allow applications to arbitrarily take the focus, which is what Minecraft seems to be doing (probably via a call to glfwFocusWindow).

So, :

• Updating LWJGL;

• Removing calls to glfwFocusWindow (maybe replacing it with an attention request?);

Should get us closer to running Minecraft under Wayland natively.

Then remains the (arguably less important) problem of automatically determining whether or not we're running under Wayland, and then passing the "-Dorg.lwjgl.glfw.libname=glfw_wayland" argument to the game or not. This post suggests checking the $XDG_SESSION_TYPE environment variable.

On my system, running Minecraft through XWayland seems to incur a near 50% performance penalty. With Ubuntu considering the switch to Wayland by default, this issue might soon become a pretty big deal for a large portion of Linux users.

EDIT:

By the looks of things, a lot of GLFW functions remain unimplemented under wayland (basically everything related to window positioning / resizing / icons). So removing those calls on Wayland is probably not a solution.

I guess we just have to wait for GLFW to either implement those functions for the wayland backend or make it easier to know if the platform supports those operations before attempting them.