[MU4 Issue] Fails to open when running native wayland #11244
Comments
|
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 Edit: I tried what I suggested, but MuseScore 4 alpha does not seem to be forwarding Qt option |
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.
Huh, using |
|
By setting env variable
Ciao, |
|
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 |
|
I finally managed to run a virtual machine with Debian wayland, so I could test it myself. Ciao |
Tested on Fedora 36 but got |
|
@Microwave-WYB : thank you for testing. You can try to set also the env variable QT_DEBUG_PLUGINS: Ciao, |
Fix musescore#11244 To use the Wayland display protocol rather than X11, firstly you must be running Wayland as your display server. Many Linux distributions allow you to choose between Wayland and X.org/X11 at the login screen. Use this command to find out which server you are currently using: echo $XDG_SESSION_TYPE Secondly, when you run MuseScore, you must opt-in to Wayland support, either via an environment variable: QT_QPA_PLATFORM=wayland ./MuseScore*.AppImage Or via a command line option: ./MuseScore*.AppImage -platform wayland Otherwise Qt will default to running in X11 mode via the Xwayland compatibility layer, which is more reliable than native Wayland support in some cases (particularly on older distributions).
|
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 |
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. |
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).
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 |
|
The Nvidia suspicion seems pretty reasonable here given that MuseScore 4 works quite well on Wayland for me, sans #15285. |
|
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. |
|
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. |
|
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 |
cbjeukendrup
moved this to First release after the upcoming one
in MuseScore Studio Backlog
cbjeukendrup
added
os: linux
|
This should be fixed in 4.4 (RC downloadable at https://musescore.org/en/node/367322). The Wayland platform plugin is packaged with the AppImage again, and the crash that happened with it (that was the reason for not packaging it in 4.2 and 4.3) was fixed in #24111. Could you please try it out and let us know your findings? Thanks! |
cbjeukendrup
added
awaiting reply from user
Wayland
It seems to work although it's not the standard platform. You have to run it with Otherwise it starts under XWayland. Many thanks for the great work. |
|
I get a bunch of errors in stdout: |
|
And the second time I start it it doesn't start. It looks like it is trying to open the previously opened file but don't file the thumbnail? I have to |
|
Try running with -F to clean up your settings (similar but more "official" way of doing the "rm" that is also more thorough), then see if the problem returns |
Still doesn't work even with the I have to manually delete the folder: |
|
What happens probably, is that when closing MuseScore, a crash would occur, and then when opening it again, a "do you want to restore the session" dialog appears, and the appearance of that dialog causes another crash. This seems more likely to be a Qt bug than a MuseScore bug. In the Qt bug tracker, I see some issues that might or might not be related; some of them would be fixed in Qt 6.2.9. You can try a Qt 6.2.9 build of MuseScore here: #24644 If not, another option is that it is caused by some missing library. You could run |
|
I ran tried the 6.2.9 build I get same issue as raffaem, i Did check depends https://pastebin.com/chaL7Fm3 |
|
The check depends output looks right... so we'll have to continue searching for the problem. I found somewhere on the internet that setting There is also a chance that it is solved in Qt 6.8. You can try this experimental Qt 6.8 build: #25016 |
|
I ran and also tried to start mscore with
I don't know how to download from #25016 because there is 0 checks, unless I just pull the repo and build it. |
|
Unfortunately those logs also don't help... Sorry about the "0 checks"; that is a GitHub bug that occurs a few times per year. I did another push to that PR and now it should be better. Here's a direct link to the download page: https://github.com/musescore/MuseScore/actions/runs/11428448318 |
|
oh nice thank you, it just works. And runs natively on wayland and menus are not spawning on the middle, I can finally scale it correctly 👍 . Also I was curious what happens if I use |
Do you mean that if you run 4.4.2 with |
|
for 6.8 build. I guess it doesn't matter because it now launches on wayland without that option. |
|
Ah okay. I suspect it has to do with how we parse command line options. If you set the |
yes. |
|
Good to know. Then we'll fix the command line options parsing before the 4.5 release. But I'm glad to hear that the Qt 6.8 update has positive results so far! |
Describe the bug
When running on a wayland compositor using
-platform wayland, the program exits with code 134To Reproduce
-platform waylandExpected behavior
Musescore should open using a wayland windowing system
Command line output
Platform information
The text was updated successfully, but these errors were encountered: