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

Wayland Support #2432

Open
ciandonovan opened this issue Apr 12, 2022 · 7 comments
Open

Wayland Support #2432

ciandonovan opened this issue Apr 12, 2022 · 7 comments
Milestone

Comments

@ciandonovan
Copy link

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
Copy link
Member

paroj commented Apr 13, 2022

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
Copy link
Author

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
Copy link
Member

paroj commented Apr 13, 2022

yes, that would be sufficient

@paroj paroj added this to the 14.x milestone Feb 2, 2024
@wjwwood
Copy link
Contributor

wjwwood commented Jun 14, 2024

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

@ciandonovan
Copy link
Author

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
Copy link
Contributor

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
Copy link
Member

paroj commented Jun 14, 2024

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

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

No branches or pull requests

4 participants