-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
4.3.dev - Problems with launching Godot/launching projects in a compositor with Xwayland disabled #92014
Comments
Are you able to test in a different wayland tiling window manager? Just to be sure it is related to this specific scenario (wayland with niri) instead of a broader scenario like wayland with any tiling window manager, or wayland with any kind of window manager, be it tiling, stacking or anything else. |
I have now tried it with a couple of compositors other than niri. My hypothesis is that the lack of "native" Xwayland support is what's causing these problems, so I tried two others based on the same framework as niri (Smithay).
The compositor based on Smithay with the largest community behind it is Cosmic, I've just finished compiling it so I'll give that a quick spin as well, although I expect Godot to work at least as well as it does on Pinnacle. I'll edit this comment in a bit. Edit: I've now tried Cosmic as well as Hyprland (a tiling Wayland compositor not based on Smithay). Godot works fine on these as well. I'm not sure if I can find a Wayland compositor not based on Smithay without Xwayland support to try that out as well. |
I'm fairly certain now that the issues are entirely dependent on whether or not Xwayland is supported. This can easily be reproduced if you use sway, which is a widely available window manager. Add |
Another niri user here, having the same issue. I can reproduce that it works in sway with xwayland enabled and doesn't work with it disabled. And that adding |
Thanks for the report (and all the confirmations)! I can't replicate the worst part of the issue personally (not running at all) on sway with Xwayland disabled but let's try to gather some more info :D
So, this part is due to a shortcoming in the way So, nothing too out of the ordinary here luckily. A workaround for now is to change the default editor backend with the editor setting With that out of the way, let's focus on the real bad part.
The real issue here is that EGL fails to intialize, due to a failed version check.
The weird thing is that your Could you try attaching a |
Here's mine if that's helpful: eglinfo -B
godot --display-driver wayland --rendering-driver opengl3 --verbose
This bit seems weird:
|
@sullyj3 yeah that did it, thank you, I finally managed to understand what's going on! So, here's how we load EGL: EGLDisplay tmp_display = eglGetDisplay(EGL_DEFAULT_DISPLAY); Can you spot the problem? Here's a bigger snippet: // NOTE: EGL_DEFAULT_DISPLAY returns whatever the O.S. deems suitable. I have
// no idea if this may cause problems with multiple display servers and if we
// should handle different EGL contexts in another way.
EGLDisplay tmp_display = eglGetDisplay(EGL_DEFAULT_DISPLAY); Yeah, that's quite some foreshadowing LOL. After a quick search, it looks like Mesa's "default display" logic is way simpler than I thought. I could finally replicate this by setting the Since you had Xwayland disabled, there was no X11 EGL display available (see the The fix should be very easy, we just have to let the backend pass what kind of display it wants to load and we should be set! I'll work on this A-absolutely-SAP! This is quite high priority. In the meantime, a workaround should be running Godot with Edit: it might be even easier, I forgot that we already passed the platform display name :D Footnotes |
That's fantastic news!
It does, yep. |
Obviously, that "quick fix" became... Whatever #92663 is. I might have spent a bit more time on this than I expected. That said, it should, on paper, fix this issue (mostly, due to a weird casting hack needed for compatibility) once and for all. Please, test it and tell me whether it works for you all! |
Tested versions
4.3.beta.custom_build.5708a3a02
(built from godot-git from the AUR).System information
Godot v4.3.beta (5708a3a) - Arch Linux #1 SMP PREEMPT_DYNAMIC Tue, 07 May 2024 21:35:54 +0000 - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 7900 XTX (RADV NAVI31) () - AMD Ryzen 9 5950X 16-Core Processor (32 Threads)
Issue description
I use niri as my daily window manager, and I'm interested in using Godot. As far as I understand, Wayland support is worked on for version 4.3 of Godot, so I'm testing it out. A thing to note about niri is that it does not have built-in Xwayland support, I'm not sure if that contributes to some of the strangeness experienced here.
I have had a couple of issues related to launching the editor, and running projects. I think they may be related, so I'm combining them all in one issue.
Some context; what
eglinfo -B
outputs:I am pretty sure all of the OpenGL versions and OpenGL ES versions are up to date here, in the context of the Wayland platform in any case.
Running with
--rendering-driver opengl3
I get a dialog error saying
The editor is unable to launch at all.
Running with
--rendering-driver opengl3_es
Pretty much the same as above, as running it with
opengl3
falls back to trying OpenGL ES as well.Running with
--rendering-driver vulkan
The editor launches, and I seem to be able to do everything I want. I do notice a warning, but it is related to a known issue in niri.
However, upon running a project, I get this snippet in the terminal:
And this dialog error saying:
But when I click OK, the project window opens anyway, and I'm able to play and interact with the window as expected.
I'm unsure why it's requesting an X11 environment upon running the project. That seems like an erroneous routine to me.
Steps to reproduce
For the happiest case:
godot --display-driver wayland --rendering-driver vulkan
For the unhappiest case, redo the steps above but omit the rendering driver flag. Observe that the editor does not launch at all.
Minimal reproduction project (MRP)
No specific project is required, although for my tests I used godotengine/godot-demo-projects/3d/platformer.
The text was updated successfully, but these errors were encountered: