Window is not created on Wayland (window doesn't respond to a configure event with a commit)

[zDEFz]

debug.log
OR
https://0x0.st/8JNp.log

Summary

Using OpenGL/Vulkan on Wayland, I cannot get a window to show up.

Steps to reproduce

• Platform: Desktop
• Framework Version: dotnet-sdk-8.0 8.0.1
• API: Vulkan and OpenGL
• API Version: Vulkan 1.2/OpenGL 4.3 Legacy/OpenGL 4.5 Core/OpenGLES 3.2

1. I downloaded OpenTaiko-Hub - which has a implementation for simply downloading the OpenTaiko package
2. I installed all required in-game dependencies
3. I asked on OFTC.net, what the WAYLAND_DEBUG report shows when trying to running the game that uses SILK.net
4. Answer "the window doesn't respond to a configure event with a commit judging by the log"
   Ran with WAYLAND_DEBUG=1 OpenTaiko
5. Judging by that, is there currently an issue for Wayland?
6. From what I can see, https://github.com/OpenTaiko configures it's stuff here https://github.com/0auBSQ/OpenTaiko/blob/main/OpenTaiko/src/Common/OpenTaiko.cs

Comments

I am not the developer, but this issue has been for long time with OpenTaiko, that the game would open on xorg, but not on Wayland.
OpenTaiko/OpenTaiko-Hub#4 (comment)

What could be done there?

[Perksey]

Hi, do you have a minimal reproduction project? OpenTaiko appears to be a very large codebase and it'll be hard to nail down the issue in there.

[zDEFz]

Hi, do you have a minimal reproduction project? OpenTaiko appears to be a very large codebase and it'll be hard to nail down the issue in there.

Don't have. I am a newcomer and have recently built workarounds because the window was created but never committed.

As for where in the code we changed something:
https://github.com/0auBSQ/OpenTaiko/commits/main/FDK/src/01.Framework/Core/Game.cs

It's not that trivial, it appears.
The recent PR on macOS appears to have fixed it for macOS but the one I did for Linux is hit or miss.

Some Wayland people say that you have to draw before creating the window but I didn't understand that.
It would help if there was a minimal program that was confirmed working across many Linux Window managers/Desktop Environments that use either X11 or Wayland.

What helped was using SILK.NET.SDL for Wayland and SILK.NET.GLFW for X.
But this does keep being a moving target. We need to re-define workarounds foreach platform.
And it's not even complete yet!
https://raw.githubusercontent.com/0auBSQ/OpenTaiko/1e4505f110e362223eff1b6255a4c5c0d2f2ebe4/special/linux_installer_standalone.bash

The implementation seems to be different on each window manager that implements it!
In some cases we even have to instruct SILK.NET.SDL to use X driver.
If we don't, well. The window does not show or we have stuff like:

And for this one we had to use OpenGL instead of vulkan and SDL backend X.
So it'd run at XWayland... Meanwhile that same config would fail in other windowmanagers.. / DE's

[Perksey]

I’m inclined to believe this is an upstream GLFW issue. Does this seem like your issue? glfw/glfw#1398

[zDEFz]

I’m inclined to believe this is an upstream GLFW issue. Does this seem like your issue? glfw/glfw#1398

That could be a small part of the many issues we are having.

The others are at SDL side, and all the things we must do to spawn a window in the first place, and then have still non-corrupted video on different (X)wayland implementations.
By the way, xwayland-satellite doesn't help here.

And if you run GLFW on Wayland environments you'd usually get a EGL Surface error.

About SILK.NET.SDL - is there no way to use it to work across systems without much tweaking?
One end must use Vulkan instead of OpenGL, the other must use SDL X driver instead of the wayland one...
That GLFW doesn't work on wayland is already known to us.

[Perksey]

I'm going to migrate this to a discussion until we have a minimally reproducible Silk.NET bug - it feels like there's a lot at play and I don't think we can move this ticket forward without specific minimal reproductions.