NeoForge
NeoForge copied to clipboard
neoforged
[Linux] Native Wayland support
I wasn't able to find a place to really suggest that in the discord server so, here I go. Hopefully someone sees this.
I know this could be a lot to ask but I'm not here to be technical this is just a wish I have. Minecraft isn't yet willing to implement this themselves for now: Minecraft Feedback Post
Would it be possible to detect and use Wayland natively ?
I think this would probably require GLFW changes but I'm not qualified to know.
This is getting quite important as it's the default for most distros and will be more and more used. Xorg is getting more and more outdated and it would also mean some safety risks to continue to only support it.
Native Wayland support is needed and the best solution as far as I know, is modloader wide support. Any other ways create incompatibilities with mods and such.
Any other option such as mods and GLFW patches I've tried didn't work on my Neoforge modpacks (game crashes). Patches and changes in GLFW libs have worked for me on fabric and quilt (with lighter and performance oriented modpacks). Having to change a library not supported by default to use the new default Display protocol natively is annoying.
Also there are some bugs using Xwayland, such as fullscreen being rendered higher than the screen. It cuts off the top centimeter of the screen or more. This is fixable but a pain to deal with.
Three screenshots here:
Another problem reported here:
I will also ask Fabric and Quilt to support native wayland at a later date.
The most I've done in technical stuff is downloading artifact builds off of github and changing the GLFW library path. I'm not experienced in Java or Linux Display protocols.
Thanks for any answers or clarifications.
Sadly this is going to be really difficult to implement. We have now opened up the option for modders to fix this themselves by providing the option to create their own ImmediateWindowProvider, and GraphicsBootstrapper.
However this needs an update of FML in NeoForge
Would providing a patched GLFW library directly in Forge when detecting Wayland not work ? This would also force miss devs not to break Wayland support as it would be integrated on forge
Would providing a patched GLFW library directly in Forge when detecting Wayland not work ? This would also force miss devs not to break Wayland support as it would be integrated on forge
No, it wouldn't work because the way LWJGL loads its libraries is incredibly cursed. Furthermore, Wayland only supports GLES/EGL which makes it incompatible with most mods already.
I did a bit of Googling and I have more questions if you don't mind answering them.
Why can I use a patched version of GLFW to play natively on wayland with Fabric/Quilt but I can't on forge ?
Would using something like Holy GL4ES like in the mobile Minecraft: Java community port be possible ? Would it result in bad performance ?
Thx for answering my questions and sorry to be so uninformed.
This is overcomplicating by a lot; and also the thing about EGL is exaggerated.
Once LWJGL gets an update to GLFW 3.4 (released 3 days ago), Wayland will be the default system. Just wait.
Can I build GLFW myself and replace the current one to get native Wayland support ?
I'm not sure if any of us can wait any longer for Wayland/XWayland and NVIDIA devs to agree on whether to implement implicit sync or explicit sync, as Minecraft on XWayland for high refresh rate displays is practically unusable when the refresh rate of the application does not exactly match the refresh rate of the display for NVIDIA proprietary drivers >=545, among the myriad of other bugs that've been left unaddressed that plague XWayland on NVIDIA. (https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317)
So far, we've been able to get Vanilla, Fabric, and Quilt running flawlessly under Wayland (the modloaders themselves, untested with additional mods), via cherry-picked patches from both https://github.com/Admicos/minecraft-wayland and https://github.com/BoyOrigin/glfw-wayland/ for GLFW 3.4. The cherrypicked patchset is available in this AUR package.
However, none of these patches seem to cut it for Forge or NeoForge, which seems to simply crash immediately upon not being able to obtain a window position because... that's just not a thing on Wayland, and I don't think it ever will be any time soon.
java.lang.IllegalStateException: GLFW error before init: [0x1000C]Wayland: The platform does not provide the window position
Excited to see neoforged/FancyModLoader#68 to address neoforged/NeoForge#393 finally merged into neoforged/FancyModLoader:main, though! One step closer to ridding of X11 completely!
How does this interact with/benefit from/depend on Project Wakefield?
Most likely, not at all - from skimming through the code, Wakefield appears to be aimed towards java.awt which isn't used by Minecraft anyway
Most likely, not at all [...] Wakefield appears to be aimed towards
java.awt
Wakefield's stated goal is for OpenJDK to get full Wayland support*, so that may extend slightly beyond awt eventually... Although I guess that still won't benefit Minecraft much seeing as most of its platform dependencies are things like GLFW, etc.
* Beginning with "full" XWayland support, and eventually native Wayland support
Furthermore, Wayland only supports GLES/EGL which makes it incompatible with most mods already.
Contrary to what quick Google search says, egl on desktop allows using opengl API just fine (early implementations probably didn't though). It's only the reference compositor implementation that used gl es.
Furthermore, Wayland only supports GLES/EGL which makes it incompatible with most mods already.
Contrary to what quick Google search says, egl on desktop allows using opengl API just fine (early implementations probably didn't though). It's only the reference compositor implementation that used gl es.
Yup, you're right - this was explained to me in Discord :sweat_smile:
Most likely, not at all [...] Wakefield appears to be aimed towards
java.awtWakefield's stated goal is for OpenJDK to get full Wayland support*, so that may extend slightly beyond awt eventually... Although I guess that still won't benefit Minecraft much seeing as most of its platform dependencies are things like GLFW, etc.
* Beginning with "full" XWayland support, and eventually native Wayland support
Again, it's better to avoid using XWayland backwards compatibility, at least for NVIDIA users, because of how broken XWayland is when it's actually running on wayland with the latest NVIDIA proprietary drivers and given direct control of rendeing infrastructure via modeset=1 kernel arguments (and potentially fbdev=1 too but I think that's mostly experiemental support for only within the scope of the linux framebuffer terminal).
Pardon my condescending snarkiness, but unless you want to ship the patches in a custom X.Org server with Explicit Sync worked in so that NVIDIA drivers can properly sync with the X.Org server running within Wayland, using XWayland at all isn't going to work, especially for higher refresh rate displays.
Hence the effort to get Minecraft running natively on Wayland, even if it's still going to be API translation layers provided by Mesa and EGLStreams for OpenGL and/or Vulkan all the way down.
The weird thing to me is that Fabric and Quilt support Wayland if a patched GLFW library is given.
How is it supported there and not on NoeForge ?
Wouldn't it be possible to do the same with NeoForge ?
If it could be implemented like Fabric, could the Wayland GLFW Library be bundled and used when needed ?
The question is getting important as Linux now runs on 4% of PCs. Wayland is the default or will be soon on most DEs.
Any updates on the issue ?
Wayland is gonna be the default in nearly all desktop environments and apps are now supporting it or are actively working on it, even the steam deck's compositor is gonna get Wayland support soon. Mojang seems to not really care about the issue but Fabric has implemented compatibility with GLFW libs patched for Wayland
Any updates on the issue ?
Wayland is gonna be the default in nearly all desktop environments and apps are now supporting it or are actively working on it, even the steam deck's compositor is gonna get Wayland support soon. Mojang seems to not really care about the issue but Fabric has implemented compatibility with GLFW libs patched for Wayland
for me it works just fine with the aur package glfw-wayland-minecraft-cursorfix (https://github.com/BoyOrigin/glfw-wayland) on 1.20.4, but on 1.20.1 i had to set earlyWindowControl to false in .minecraft/config/fml.toml
Any updates on the issue ? Wayland is gonna be the default in nearly all desktop environments and apps are now supporting it or are actively working on it, even the steam deck's compositor is gonna get Wayland support soon. Mojang seems to not really care about the issue but Fabric has implemented compatibility with GLFW libs patched for Wayland
for me it works just fine with the aur package glfw-wayland-minecraft-cursorfix (https://github.com/BoyOrigin/glfw-wayland) on 1.20.4, but on 1.20.1 i had to set earlyWindowControl to false in .minecraft/config/fml.toml
OMG thank you that solves everything. Thanks !
It can't be that hard to add that in fml, just disable that rule when running on Wayland.
Thank You for real you solved all my XWayland issues. <3
It fixed:
-
The game window not being aligned with the screen (pictures at the top).
-
A crash every time I pressed the Quit Game button (an entire JDK 17 crash).
So I see disable the earlyWindowControl seems to have fixed native Wayland launching, along with the patched glfw. That's good!
Small problem though. If I try it; as soon as I resize the window:
And it just sort of... Washes white until nothing is visible anymore.
With the patched GLFW for Wayland I get this kind a of bug where the mouse cursor is shown even when it's supposed to be hidden:
Any solutions ?
i found another workaround it doesn't require patched glfw just set these environment variables : __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink it runs minecraft via zink also i think you need mesa installed the best part is this works on every version, every loader i tried even pre 1.13
So I see disable the earlyWindowControl seems to have fixed native Wayland launching, along with the patched glfw. That's good!
Small problem though. If I try it; as soon as I resize the window:
And it just sort of... Washes white until nothing is visible anymore.
are you using nouveau?
i found another workaround it doesn't require patched glfw just set these environment variables : __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink it runs minecraft via zink also i think you need mesa installed the best part is this works on every version, every loader i tried even pre 1.13
Zink hurts performance since it translates OpenGL to Vulkan, especially with like e.g shaders, so this is not ideal
Hey, so remember way back in March when I said "I'm not sure if any of us can wait any longer for Wayland/XWayland and NVIDIA devs to agree on whether to implement implicit sync or explicit sync"?
Well, silly me for being impatient, explicit sync finally made it into XWayland and related projects, so maybe this issue can be revisited with XWayland as the stopgap for now.
Personally, I've moved back to X11, as there are plenty of other regressions that have come out of this that have made Wayland unusable for me for a considerable amount of time now.
UPDATE: 1 week later after posting this and getting the Nvidia 560 beta drivers, Wayland suddenly works perfectly again :)
as of nvidia 555 all versions work perfectly for me, forgot about this thread completely
i found another workaround it doesn't require patched glfw just set these environment variables : __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink it runs minecraft via zink also i think you need mesa installed the best part is this works on every version, every loader i tried even pre 1.13
Zink hurts performance since it translates OpenGL to Vulkan, especially with like e.g shaders, so this is not ideal
I know at the time I was just happy to see it work and didn't do much testing