POC: OpenCPN under Wayland (w.EGLX)

[Tarnyko]

Hi folks,

I've been working, for the last couple of days, on a port of OpenCPN to native Wayland
(i.e. not using an emulation layer like XWayland).

There were 2 main blockers for this :
- OpenCPN massively uses legacy OpenGL, whereas Wayland only supports OpenGL ES ;
- OpenCPN uses the wxGLCanvas wxWidget to render its navigation map, which itself uses GLX, whereas Wayland requires EGL.

So I wrote a little wrapper named EGLX which basically redirects X11/GLX calls to Wayland/EGL ones.
Then I patched wxWidgets to integrate the wrapper. And then I patched OpenCPN itself, to use GTK+3, integrate the wrapper, the jwzGLES one, and to disable some unsupported GL calls (mostly GLU and tessellation).

The result is very exciting :



(click here for a larger version)


This doesn't work perfectly yet : right-click on the map freezes it, some commands make the program crash, the toolbars look like independant windows...

Unfortunately, I have to pause this work for the moment, as I got other priorities. But if noone objects, I will list caveats, bugs and "todos" in a following post, so anyone interested can take up with the project.

[Tarnyko]

So here is a video, which is maybe better than a single screenshot :

OpenCPN under Wayland (w.EGLX) - YouTube

So here are remainder challenges for a native port of OpenCPN :

- port all OpenGL code to OpenGLES (2 or 3 preferably). Using a wrapper won't be a viable option until someone ports the legacy desktop OpenGL backend to Wayland -which doesn't seem to be a priority. Plus, it will be necessary for mobile systems (Android, iPhone...) anyway.

- update the code in wxWidgets to add native support for an EGL canvas (though the wrapper works well enough for now) ;

- reimplement the toolbar and statusbar as wxToolbar and wxStatusBar instead of wxFrames. The reason being that GTK+/Wayland now treats these objects as separate surfaces, which means separate windows.

They won't follow the main frame though, because the code does this :
m_position.x ... m_position.y

Wayland doesn't give absolute coordinates ; these values are always "0", so the toolbar and statusbar never move from their starting positions. Making them regular wx/Gtk widgets will draw them to the main window (losing some flexibility though). Another option would be to use the Wayland subsurface api to redraw them in the window context, but it's still tricky and unimplemented in GTK+.

Thanks for your attention, happy sailing.

[dominig]

Thanks for that investigation.
With Wayland growing in acceptance by the major Linux distro, suport of Wayland will become a key issue.
It's also a nice path to create an Android version of OpenCPN as a project enabling Wayland Apps in Android is available.
Having the details of what must be changed to become Wyaland compatible would be very valuable.

[tobixen]

Any further progress here?

I've ordered a Jolla pad, and would love to use it for navigation. As far as I've understood, wayland support is a requirement for running graphical applications on it.