[MU4 Issue] Fails to open when running native wayland

[crispyricepc]

Describe the bug When running on a wayland compositor using -platform wayland, the program exits with code 134

To Reproduce

1. Execute the appimage from the command line with the argument -platform wayland

Expected behavior Musescore should open using a wayland windowing system

Command line output

/usr/lib64/pipewire-0.3/jack/libjack.so.0
/lib64/libnss3.so
QEventLoop: Cannot be used without QApplication
QEventLoop: Cannot be used without QApplication
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

/tmp/.mount_MuseScpdjKJ6/AppRun: line 26: 23352 Aborted                 (core dumped) "${APPDIR}/bin/mscore-portable" "$@"

Platform information

• OS: Linux
• Window Manager: GNOME 41 Wayland

[AntonioBL]

I think because only the library libqxcb.so is included at installation time in the AppImage distribution.

If you want, you can extract to AppImage content by running with option --appimage-extract (I think it should work) and then copy some qt libraries from folder gcc_64/plugins/platforms to folder plugins/platforms. You can then repack the AppImage with appimagetool, or maybe simply locally run MuseScore from inside the extracted folder. You can find the archive of the Qt installation currently used for linux compilation here: https://s3.amazonaws.com/utils.musescore.org/Qt5152_gcc64.7z

Edit: I tried what I suggested, but MuseScore 4 alpha does not seem to be forwarding Qt option -platform to its Qt infrastucture, so even -platform=xcb does not work for me

[crispyricepc]

I think because only the library libqxcb.so is included at installation time in the AppImage distribution.

Should this be included in the AppImage for Linux then? AFAIK there's no downside to including this library since it just allows wayland users to not have to rely on xwayland.

Edit: I tried what I suggested, but MuseScore 4 alpha does not seem to be forwarding Qt option -platform to its Qt infrastucture, so even -platform=xcb does not work for me

Huh, using -platform=xcb seems to give a response for me, and the relevant commits on the MU4 branch suggests that the arguments are being passed to Qt.

[AntonioBL]

By setting env variable QT_QPA_PLATFORM=<name of the plugin> before launching the AppImage seems to work for me (but then it cannot run wayland since I am using X11). You can thus try this:

• extract the (MuseScore 4.0 Alpha) AppImage content by running it with option --appimage-extract; a folder called squashfs-root is created
• download https://s3.amazonaws.com/utils.musescore.org/Qt5152_gcc64.7z
• copy the "wayland" plugins from folder plugins/platforms inside the 7z archive to squashfs-root/plugins/platforms
• cd squashfs-root
• run QT_QPA_PLATFORM=wayland ./AppRun

Ciao, ABL

[crispyricepc]

It looks like quite a few files from that download link are needed to get wayland working. I can't figure out which ones at the moment are necessary, and I've failed to get it working at all on my laptop

[AntonioBL]

I finally managed to run a virtual machine with Debian wayland, so I could test it myself. Here you can find an AppImage of MuseScore 4.0 first alpha repacked with those platform plugins as well as the Qt-plugin folders wayland-decoration-client, wayland-graphics-integration-client and wayland-shell-integration: https://drive.google.com/file/d/1naata5hkyLyZqYqlBs-bGCJbvzFrWlT9/view?usp=sharing (I extracted the AppImage with --appimage-extract, copied the files and then repacked with appimagetool, https://appimage.github.io/appimagetool/ ) If you launch it with env variable QT_QPA_PLATFORM=wayland or QT_QPA_PLATFORM=wayland-egl it should use native wayland.

Ciao

[Microwave-WYB]

I finally managed to run a virtual machine with Debian wayland, so I could test it myself. Here you can find an AppImage of MuseScore 4.0 first alpha repacked with those platform plugins as well as the Qt-plugin folders wayland-decoration-client, wayland-graphics-integration-client and wayland-shell-integration: https://drive.google.com/file/d/1naata5hkyLyZqYqlBs-bGCJbvzFrWlT9/view?usp=sharing (I extracted the AppImage with --appimage-extract, copied the files and then repacked with appimagetool, https://appimage.github.io/appimagetool/ ) If you launch it with env variable QT_QPA_PLATFORM=wayland or QT_QPA_PLATFORM=wayland-egl it should use native wayland.

Ciao

Tested on Fedora 36 but got

> QT_QPA_PLATFORM=wayland ./MuseScore-4.0.0.2059995262-x86_64_wayland.AppImage               
/usr/lib64/pipewire-0.3/jack/libjack.so.0
/lib64/libnss3.so
QEventLoop: Cannot be used without QApplication
QEventLoop: Cannot be used without QApplication
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

/tmp/.mount_MuseScYQ2xEe/AppRun: line 26:  9206 Aborted                 (core dumped) "${APPDIR}/bin/mscore-portable" "$@"

[AntonioBL]

@Microwave-WYB : thank you for testing. You can try to set also the env variable QT_DEBUG_PLUGINS: export QT_DEBUG_PLUGINS=1 before launching the AppImage. It should give more information on why it fails to load the "wayland" plugin.

Ciao, ABL

[p-mitana]

Hello, what is the status of this issue?

Actually, major Linux distributions currently use Wayland by default, which renders MuseScore not working at all currently. Those more tech-savvy may attempt relogging to X session and try then, but that's not what should be required.

Currently updating to stable MuseScore 4 makes the application not starting at all for most Linux users, so in my opinion this should definitely a top priority stability issue.

[crispyricepc]

Hello, what is the status of this issue?

Actually, major Linux distributions currently use Wayland by default, which renders MuseScore not working at all currently. Those more tech-savvy may attempt relogging to X session and try then, but that's not what should be required.

Currently updating to stable MuseScore 4 makes the application not starting at all for most Linux users, so in my opinion this should definitely a top priority stability issue.

This shouldn't be the case. Qt will choose the best available platform (in the case of MuseScores appimage, this is xcb), which runs fine on XWayland. The only case that musescore would fail to launch is by having QT_QPA_PLATFORM set to something other than xcb, or your -platform flag is being passed

[p-mitana]

This shouldn't be the case. Qt will choose the best available platform (in the case of MuseScores appimage, this is xcb), which runs fine on XWayland

Unfortunately it is the case. At least on Fedora 37 with GNOME 43 and NVidia drivers. It tries to start, but window is black and the application is not usable at all. I have to relog to X to use the program.

Actually with 3.6 I had serious flickering issues while running with XWayland, but setting the QT_QPA_PLATFORM=wayland made it work better (still not without issues though). For 4.0 none of the options works.

I tried the Flatpak version where I can set QT_QPA_PLATFORM=wayland, but the application fails to start anyway.

[crispyricepc]

Actually with 3.6 I had serious flickering issues while running with XWayland, but setting the QT_QPA_PLATFORM=wayland made it work better (still not without issues though). For 4.0 none of the options works.

I also use an Nvidia GPU and had the same issues with 3.6. But this is an issue with Nvidia drivers and XWayland across most apps, not just musescore (it's why I made the request to include Wayland in the appimage).

I tried the Flatpak version where I can set QT_QPA_PLATFORM=wayland, but the application fails to start anyway.

Again, I suspect Nvidia drivers are to blame. On my machine, any hardware accelerated Qt completely crashes on Wayland. I think the reason this didn't happen on 3.6 is because they were using the software rendered QtWidgets instead of GPU accelerated QtQuick. But that assumption mostly comes from my experience with working on Qt applications in my own time

[Ocawesome101]

The Nvidia suspicion seems pretty reasonable here given that MuseScore 4 works quite well on Wayland for me, sans #15285.

[p-mitana]

Yes, most likely this is the case.

Maybe it still could be looked into and fixed somehow? MU3.6 had some glitches, but it was usable on this configuration.

[crispyricepc]

For what it's worth, an Nvidia update has fixed the accelearted Qt issue.

The AppImage still doesn't include the necessary libraries for Wayland though, although it's less of an issue for most people as the distros have updated MuseScore in the repos anyway.

[danielzgtg]

I tried running MuseScore 4 after building from cmake. That allowed it to choose wayland. All the menus appear in the wrong position:

This is on a 200% hidpi screen. Wayland probably works on a regularly sized screen. A year ago this problem plagued all of the apps on my computer. Input methods, KDE apps, and Anki all showed their overlay menus in the wrong position, but they fixed them problem after a few updates. Perhaps MuseScore needs to find and include the fix.

The whole reason I was investigating Wayland is because the font and icon sizes were unusably small on X11. I ended up fixing the problem in X11 and using it instead, by using QT_QPA_PLATFORM=xcb QT_SCALE_FACTOR=2 builds/Linux-Qt-usr-Make-Release/install/bin/mscore or QT_SCALE_FACTOR=2 ./MuseScore-4.0.1.230121751-x86_64.AppImage. I have "Legacy Applications (X11): Apply scaling themselves" in KDE5 Display Configuration. QT_SCALE_FACTOR=2 must not be set system-wide or else that'll cause Qt apps that support Wayland to be too big.

[crispyricepc]

I tried running MuseScore 4 after building from cmake. That allowed it to choose wayland. All the menus appear in the wrong position

Issue is known, see #15285

[raffaem]

@RomanPudashkin looks like despite #13781 Wayland plugin is still not bundled in the AppImage?

I'm getting this:

➜  QT_QPA_PLATFORM=wayland QT_QPA_PLATFORMTHEME=qt5ct ./MuseScore-Studio-4.3.2.241630832-x86_64.AppImage 
/usr/lib/libjack.so.0
/usr/lib/libnss3.so
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: offscreen, xcb.

/tmp/.mount_MuseScjluC6p/AppRun: line 26: 46403 Aborted                 (core dumped) "${APPDIR}/bin/mscore4portable" "$@"

[cbjeukendrup]

In 4.2, the wayland plugin was packaged, but we undid that for 4.3 because it turned out to cause problems: because of a version incompatibility between this plugin and some library from wayland itself (I don't remember the details), MuseScore would crash. So we reverted it, because running with xcb is at least better than not running at all. We still hope to fix this in the future. I seem to recall that dropping support for Ubuntu 20.04 might facilitate that, but it might still be too early to do that.

[raffaem]

In 4.2, the wayland plugin was packaged, but we undid that for 4.3 because it turned out to cause problems: because of a version incompatibility between this plugin and some library from wayland itself (I don't remember the details), MuseScore would crash. So we reverted it, because running with xcb is at least better than not running at all. We still hope to fix this in the future. I seem to recall that dropping support for Ubuntu 20.04 might facilitate that, but it might still be too early to do that.

Oh I see.

I obtain flickering issues with xcb.

I downloaded the latest nightly builds where the wayland seems to be present, but it crashes indeed.

[raffaem]

@cbjeukendrup So, since this bug report is closed, this is now tracked by #20550 right?

[cbjeukendrup]

I'll reopen this issue. That should actually have been done directly after merging https://github.com/musescore/MuseScore/pull/20391. It's also somewhat covered by https://github.com/musescore/MuseScore/issues/21528, but also not entirely, so I think it's good to have this issue open.