Slicer on Wayland

Development
,
1

Hey everyone,
I’ve been messing around a bit today with Slicer due to performance issues and noticed it’s actually running in XWayland on my openSuse TW + KDE plasma Wayland system.
Upon starting from the commandline:

➜  ~ /opt/slicer/Slicer-5.3.0-2023-08-01-linux-amd64/Slicer
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
Switch to module:  "Welcome"

indeed, the platform plugins shipped in the binary download are the following:

➜  ~ ls /opt/slicer/Slicer-5.3.0-2023-08-01-linux-amd64/lib/QtPlugins/platforms/           
libqxcb.so

While the ones available on my system:

➜  ~ ls /usr/lib64/qt5/plugins/platforms 
libqeglfs.so       libqminimal.so    libqwayland-egl.so             libqwayland-xcomposite-glx.so
libqlinuxfb.so     libqoffscreen.so  libqwayland-generic.so         libqxcb.so
libqminimalegl.so  libqvnc.so        libqwayland-xcomposite-egl.so

and unfortunately symlinking any of the files from the latter to the former is unsuccessful, Qt finds and correctly identifies the lib, but stops with version incompatibility.

If my understanding is right, would it be imaginable to have the platform plugins shipped with Slicer?

2

Thank you for the investigation and sharing the results.

I’ve tried to set up a linux box with wayland a couple of months ago and found that basically none of the commonly used remote desktop software supported it yet, so it did not look like that wayland is really ready for replacing X protocol. Do you find that wayland is actually practically usable? (for me, no standard remote desktop software

If yes, and you think that it is time for Slicer to support it, too, then we could use some of your experience and help with this. Could you build Slicer as described here and see if it works? Then try to make a package (make package) and see if the wayland platform plugin files are included in the created package.

  • If the wayland plugin files are not included then SlicerBlockInstallQtPlugins.cmake may need to be modified.
  • If the wayland plugin files are included it means that the Qt that is used on factory machines need to be built with wayland enabled.

@Sam_Horvath @jcfr please chime in if you have some suggestions or have experience with wayland support.

3

Looking at the Slicer sources, we can indeed observe that we are only packaging xcb plugins

means that the Qt that is used on factory machines need to be built with wayland enabled.

Since on Linux, we are re-packaging the official binaries, addressing this should not require to build Qt from source.

Wayland plugins

The plugins available in Qt 5.15.2 are the following:

$ cd /opt/qt/5.15.2/gcc_64/plugins

$ ls -1 wayland-decoration-client/
libbradient.so

$ ls -1 wayland-graphics-integration-client/
libdmabuf-server.so
libdrm-egl-server.so
libqt-plugin-wayland-egl.so
libshm-emulation-server.so
libvulkan-server.so
libxcomposite-egl.so
libxcomposite-glx.so

$ ls -1 wayland-shell-integration/
libfullscreen-shell-v1.so
libivi-shell.so
libwl-shell.so
libxdg-shell.so
libxdg-shell-v5.so
libxdg-shell-v6.so

Distributing Wayland plugins

It would be straightforward to distribute additional plugins.

@d-vogel Could you help use evaluate which ones ?

Without recompiling, you should be able to simply copy the missing plugins found after installing Qt 5.15.2 following these instructions

Documentation

1 Like
4

Well wayland is now default on quite a few distributions (Fedora and openSuse at least), KDE has stated Wayland is their default target for Plasmashell and I think Gnome is also very much focused on Wayland.

I’ve been running plasmashell with wayland for around two years now and I think all apps installed from the distro repo are using wayland (including Paraview with better performance with Wayland). The last apps that don’t are apps installed via flatpack (MS Teams) and Electron apps (VSCode, Slack, Spotify, Obsidian) both require adding a flag manually, I applied them for Teams and VSCode and again the animations are smoother.

As for the source build, it might be challenging in terms of time, I will first investigate the direction provided by @jcfr.

1 Like
5

To my understanding, apps in plasmashell-wayland are in fact using xwayland, and won’t start without X libraries. Last time I tried with a pure Wayland desktop like Weston, even kcalc did not launch. Will try again, it’s just doubtful that the plethora of applicaions in a Linux distribution have been ported to pure Wayland.

6

XWayland apps get listed by xlsclients, only those I talked about in my previous message pop up in the list.

7

There’s no reason Wayland shouldn’t be supportable either via the methods Jc suggested if someone has the time to invest in it, or by waiting for the Qt6 port. I’m not particularly motivated since X works fine for my use cases and remote desktop support in Wayland seems to be lagging.

8

I will first investigate the direction provided by @jcfr

@d-vogel Thanks for working on that. The idea would be to understand how to update variable SlicerBlockInstallQtPlugins_subdirectories referenced above.

In addition of the libraries listed above, there are also:

$ cd /opt/qt/5.15.2/gcc_64/plugins

$ ls -1 platforms/libqwayland-*so
platforms/libqwayland-egl.so
platforms/libqwayland-generic.so
platforms/libqwayland-xcomposite-egl.so
platforms/libqwayland-xcomposite-glx.so

Reading this page is informative:

After we understand which plugins are required and how to env. variable like these ones:

  • QT_XCB_GL_INTEGRATION
  • QT_WAYLAND_CLIENT_BUFFER_INTEGRATION

we will understand how to update the list of plugins to package and provide guidance.

The env. variable should be set in a way for also compatible with how Qt and VTK are integrated.

Additional resources: