Skip to content
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

OpenXR: Add support for Wayland on Linux #97771

Merged
merged 1 commit into from
Oct 25, 2024

Conversation

dsnopek
Copy link
Contributor

@dsnopek dsnopek commented Oct 3, 2024

Adds support for initializing OpenXR with Wayland on Linux.

Some notes about the OpenXR side of this:

  • Monado is an OpenXR runtime that works on Linux
  • If you run it like QWERTY_ENABLE=1 OXR_DEBUG_GUI=1 monado-service it works as an OpenXR "simulator", where it'll show what the headset sees in a window and allow you to use keyboard and mouse to control the virtual headset
  • In the standard XR_KHR_opengl_enable extension, there is a XrGraphicsBindingOpenGLWaylandKHR struct, that supposedly allows initializing OpenXR on Wayland, however, as far as I know, it's not supported on any OpenXR runtime, and according to the Monado folks, it's insufficient to support Wayland (ie it doesn't take in enough information to make it possible to work)
  • So, the Monado people created the XR_MNDX_egl_enable extension, which allows initializing OpenXR when using EGL, including on Wayland, which is currently supported on the Monado runtime, and the Pico 4 Ultra runtime. As far as I know, at the moment, this is the only way to support Wayland with OpenXR at all
  • This PR adds support for the XR_MNDX_egl_enable extension, but only for Wayland on Linux. Even though we'd theoretically be able to use it with X11 when EGL is used, or on Android, the other extensions we use for supporting those platforms work on more OpenXR runtimes (and even work with Monado too).

TODO:

  • Actually test it! My local machine currently uses the proprietary nvidia drivers with X11 - I'll need to get Wayland going :-)
  • Support compiling with x11=no

Assuming I get the 2nd point going, this will supersede PR #73504

Supersedes #73504

Bugsquad edit: fixes #70199

@dsnopek dsnopek added this to the 4.x milestone Oct 3, 2024
@dsnopek dsnopek requested review from a team as code owners October 3, 2024 15:28
@dsnopek dsnopek marked this pull request as draft October 3, 2024 15:28
@dsnopek dsnopek force-pushed the openxr-linux-egl branch 3 times, most recently from 01c3299 to 21617c1 Compare October 4, 2024 15:30
@dsnopek dsnopek changed the title [DRAFT] OpenXR: Add support for Wayland on Linux OpenXR: Add support for Wayland on Linux Oct 4, 2024
@dsnopek dsnopek marked this pull request as ready for review October 4, 2024 16:45
@dsnopek
Copy link
Contributor Author

dsnopek commented Oct 4, 2024

This is working for me locally now!

I tested with the "Pop" desktop on Wayland, together with the Monado runtime.

If anyone wants to test themselves, you'll need to:

  1. Start Monado via QWERTY_ENABLE=1 OXR_DEBUG_GUI=1 monado-service
  2. Update your project (which uses OpenXR, of course) to use the "wayland" display server in Project Settings, and enable verbose output (to get some messages to help you know it's working)
  3. Run it!

You should be able to see output in the console that you ran the game from to indicate that it's using Monado, Wayland and EGL, for example, this is what I see:

odot Engine v4.4.dev.custom_build.21617c14a (2024-10-04 15:30:51 UTC) - https://godotengine.org
OpenXR: Running on OpenXR runtime:  Monado(XRT) by Collabora et al 'GIT-NOTFOUND'   21.0.0
WARNING: Can't obtain the XDG decoration manager. Libdecor will be used for drawing CSDs, if available.
     at: init (platform/linuxbsd/wayland/wayland_thread.cpp:3731)
OpenGL API 3.3.0 NVIDIA 560.35.03 - Compatibility - Using Device: NVIDIA - NVIDIA GeForce RTX 4070 Ti

OpenXR: Requested OpenGL version does not meet the minimum version this runtime supports.
- desired_version  3.3.0
- minApiVersionSupported  4.5.0
- maxApiVersionSupported  4.6.1023
OpenXR: Trying to initialize with OpenGL anyway...
 INFO [xrt_gfx_provider_create_gl_egl] Extension availability:
 INFO [xrt_gfx_provider_create_gl_egl]   - GL_EXT_memory_object: true
 INFO [xrt_gfx_provider_create_gl_egl]   - GL_EXT_memory_object_fd: true
 INFO [xrt_gfx_provider_create_gl_egl]   - GL_EXT_memory_object_win32: false
 INFO [xrt_gfx_provider_create_gl_egl]   - GL_OES_EGL_image_external: false
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_ANDROID_get_native_client_buffer: false
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_ANDROID_native_fence_sync: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_EXT_image_dma_buf_import_modifiers: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_fence_sync: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_image: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_image_base: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_reusable_sync: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_wait_sync: true
 INFO [xrt_gfx_provider_create_gl_egl] Using GL memory object swapchain implementation

@Riteo
Copy link
Contributor

Riteo commented Oct 5, 2024

Thank you!

Unfortunately it seems like I can't test this PR properly because my setup does not support the GL_OVR_multiview and the GL_OVR_multiview2 extensions. They got recently merged into zink (OGL-over-Vulkan) but even a HEAD build gives me errors regarding other multiview builtins which should work but they don't and I just gave up.

So testing wise I'll limit myself by saying that I can confirm that it fixes the x11=no. I gave a rough look at the code before testing and it looked fine.

I'm a bit tired so if you don't see me officially approving it now I'll do so tomorrow after taking a closer look.

#include "thirdparty/glad/glad/egl.h"
#else
#include <EGL/egl.h>
#endif // GLAD_ENABLED
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should one day put this block into some shared include, like we did with other GL-related stuff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that'd be nice: this same "glad/egl.h" vs "EGL/egl.h" is done in a couple other places. It's always tricky with platform includes, though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose we can do this in a separate PR sometime

static XrGraphicsBindingOpenGLXlibKHR graphics_binding_gl;
#endif
#ifdef EGL_ENABLED
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly this include means that the XR_MNDX_egl_enable extension will be handled also on X11, although it will only be used with the Wayland backend, right?

Are there plans of using this extension also with X11 or other EGL-enabled gl managers, like the ANGLE ones?

Copy link
Contributor Author

@dsnopek dsnopek Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly this include means that the XR_MNDX_egl_enable extension will be handled also on X11, although it will only be used with the Wayland backend, right?

Yes, on Linux we'll include the code for initializing OpenXR on both GLX and EGL, but only actually use the EGL version if we're on Wayland.

Are there plans of using this extension also with X11 or other EGL-enabled gl managers, like the ANGLE ones?

I haven't tested this (I should!) but I don't think OpenXR will be able to correctly initialize with ANGLE, because the OpenXR runtime will be using "real EGL", but we'll be passing it handles (EGLDisplay, EGLConfig, etc) from ANGLE, which I think it'll just see as invalid.

But I'll give it a test when I have a chance!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right. This is absolutely not blocking. Just a curiosity :D

Copy link
Contributor

@Riteo Riteo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really know the OpenXR API that well so TIWAGOS but everything looks fine! Thank you for fixing this issue, now "full-featured" Wayland-only builds are a thing!

@Repiteo Repiteo modified the milestones: 4.x, 4.4 Oct 25, 2024
Copy link
Contributor

@Repiteo Repiteo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Buildsystem/CI changes check out 👍

@Repiteo Repiteo merged commit 07e759b into godotengine:master Oct 25, 2024
19 checks passed
@Repiteo
Copy link
Contributor

Repiteo commented Oct 25, 2024

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot compile Godot without x server - scons x11=no
3 participants