Wayland Support

[ciandonovan]

When building OGRE with the flag -DOGRE_GLSUPPORT_USE_EGL=1 to attempt to get it to run natively on Wayland, the sample applications still call on functions that require GLX or expect an X11 display socket and attempt to connect to that instead.

There was some discussion on your forums here (https://forums.ogre3d.org/viewtopic.php?t=96208) where others also attempted this, but from what I could see it never got resolved.

The application I'm trying to build is RViz, which uses the OGRE engine, and my aim is to have it work natively with the Weston Wayland compositor. Windows' WSL uses Weston internally for graphical Linux applications, and there's footage here (https://devblogs.microsoft.com/commandline/the-initial-preview-of-gui-app-support-is-now-available-for-the-windows-subsystem-for-linux-2/) of RViz running on Weston in WSL. However, I'm not familiar with how WSL works internally and whether they in fact use XWayland for compatibility.

Does there exist an option in OGRE to disable the X11/GLX components and have it use EGL/Wayland exclusively, or would that require significant refactoring to achieve?

[paroj]

to run Ogre on Wayland, we also need a WaylandWindow and WaylandEGLSupport implementation for EGL - similarly to what we have for X11 or Android right now:
https://github.com/OGRECave/ogre/tree/master/RenderSystems/GLSupport/src/EGL

as you can see there is currently none, so feel free to write one and contribute 😄

[ciandonovan]

Thanks for pointing me in the right direction!

So writing a OgreWaylandEGLSupport.cpp/OgreWaylandEGLWindow.cpp and replicating the functionality from the other EGL render systems with Wayland-equivalent functions should be sufficient for Wayland-native windowing? Or are there other areas of ORGE that would also need refactoring?

[paroj]

yes, that would be sufficient

[wjwwood]

Just checking in here, @ciandonovan did you manage to make any progress on this?

[ciandonovan]

Unfortunately not, we'd love to use RViz plugins on Weston/Wayland in an embedded usecase, but this is the blocker. I saw it was added to the milestones for the next major release so hopeful there's movement somewhere, especially now since more distros are moving the Wayland by default too.

[joakimono]

I’m working on an attempt to achieve this. I have pushed my current progress on this in a forked repo on my github account. There are several issues that needs to be fixed before a pull request is ready.

I have managed to run my implementation with the sample application with pure Wayland (by setting SDL_VIDEODRIVER=wayland), but it is not robust. Barebone window creation will not work, neither will qt. WindowEventUtilities needs to be ported to use Wayland instead of X11 stuff.

My approach only supports either Wayland OR X11 at compile time, not both, which both SDL and qt do. I would prefer to allow supporting both, but I think this will require more refactoring of Ogre.

Unfortunately, my progress on this will be unpredictable, but I hope to find time to complete it during the next few months.

[paroj]

Barebone window creation will not work, neither will qt. WindowEventUtilities needs to be ported to use Wayland instead of X11 stuff.

actually all of this is fine. WindowEventUtilities are only needed for barebone window creation. However for new code I would not bother with that. E.g. the Vulkan render system just assumes that the window is externally created and does not attempt to create a barebone one. Given that SDL exists, I do not think it is worth the effort re-implementing that.

My approach only supports either Wayland OR X11 at compile time,

this is fine for a first version, we can improve on that later

[joakimono]

Since WindowEventUtilities are not needed (and perhaps also not Qt) there is less remaining work. My impl hides the X11-specifics if Ogre is compiled with Wayland. There are no explicit dependencies on X11 or Xaw or the like.

I made an attempt to also support Qt, but I come across several challenges, which might be overcome, but not with ease, at least from my part. I add this progress to the draft PR for reference.

[paroj]

especially now since more distros are moving the Wayland by default too.

for reference, when using Wayland natively, there will be performance regressions if the compositor lacks some extensions - even compared to using XWayland.

See libsdl-org/SDL#9345

[paroj]

fixed by #3142