CI/Linux: Disable Wayland and spring cleaning #10179
Conversation
We don't need it. Adding directories through portals in Qt works fine.
|
It is absurd to remove wayland support completely just because of insignificant bugged features like window position saving or csd. It was working perfectly at least for me and even if everything said above was true the emulator was completely usable with no noticeable gameplay inconveniences. This PR is completely delirious and says a lot (but nothing good) about PCSX2 developing standards. |
|
it's not just bugged windows position, if you did more reading of the OP before raging through your keyboard, you'd see there are other problems. if you want to use it, you're free to re-enable it and build it yourself, but for us, wayland is a constant pain in the neck and an inferior experience. |
|
It's not removed at all. If you read the title or description, you'd see it is disabled on our release builds, because it's nothing but headaches for us, because of its broken by design nature causing issues for users. I listed a bunch of them in the OP as well. We're sick of getting blamed for bugs in wayland compositors, while the various committees sit around arguing with each other, finally decide on standard ways of doing things after half a decade, then GNOME ruins it all by refusing to implement it. If you use the flatpak, it's even just a single flatseal command to re-enable. PCSX2 runs fine under XWayland. In fact, it runs much better than under native WL, because it doesn't have all the above issues. Don't get me wrong, X11 is terrible code, and should've been purged a decade ago. But Wayland is just broken, and everyone would rather sit around arguing with each other instead of actually addressing the design flaws. Edit: I probably should clarify the reason the libs were removed from the AppImage - it's because I couldn't find a way to override environment variables without using a custom AppRun script, and the whole reason to moving to linuxdeploy was so that it'd be less error-prone and maintenance work. Plus, if we overrode it in AppRun, then you couldn't override it yourself anyway. |
|
I'm sorry if the FR issue was an inconvenience or if my comment was seen as an insult or a lack of respect, it wasn't my intention. In my case, the appImage doesn't boot after the update with wayland enabled, which made me think that it was removed, and I just wanted to know if that's the case and if it could be brought back (the reason for the FR issue was to formalize my pettition). |
|
It's only disabled in the app image, if you build it yourself it will still have wayland. Flatpak also has a switch to enable wayland. |
|
It works fine under WL sessions, with XWayland. Kam and I both checked it. If you solve all the issues I listed above with Wayland, then I'd be more than happy to re-enable it in Release builds. But I can't see how that is possible, especially with GNOME, and we're tired of users blaming us for its brokenness. |
|
For some perspective on why we, as developers, are frustrated with Wayland: Have a read of this latest mess: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 It's not the first time such a proposal has been put forward. Something that developers need for their applications to work properly on WL (particularly multi-window applications), and it gets vetoed. Every other OS manages this fine. But apparently we're in the wrong for not conforming to some warped view of how applications should be, despite our applications working fine on every other platform. Especially the GNOME folks, not everyone wants to use the rubbish that they call GTK. And don't give me the "but I don't use GNOME, I use wlroots/kwin/whatever, it works fine", that's good for you, then build from source, or use the flatpak+flatseal. Unfortunately, a good chunk, if not a majority of Linux users end up with GNOME, and they get the crap experience, and we can't really say "if GNOME, disable WL", since Qt makes that decision, not us. Have a look through the PCSX2 source for references to Wayland. Here's some: $ grep -ri "wayland" pcsx2-qt/
pcsx2-qt/MainWindow.cpp:// Qt Wayland is broken. Any sort of stacked widget usage fails to update,
pcsx2-qt/MainWindow.cpp: // .. except on Wayland, where everything tends to break if you don't recreate.
pcsx2-qt/MainWindow.cpp: // make sure we're visible before trying to add ourselves. Otherwise Wayland breaks.
pcsx2-qt/MainWindow.cpp: // Don't risk doing this on Wayland, it really doesn't like window state changes,
pcsx2-qt/MainWindow.cpp: // Wayland's a pain as usual, we need to recreate the window, which means there'll be a brief
pcsx2-qt/DisplayWidget.h: // Wayland is broken in lots of ways, so we need to check for it.
pcsx2-qt/DisplayWidget.cpp: // We only need this on Wayland because of client-side decorations...And you wonder why we just throw our hands in the air and say "bugger this". As an OS developer, you need to have applications, or it's kinda pointless. By pushing developers away from your platform, because they're tired of dealing with complaining users, about things that are 100% out of their control, you have nobody to blame but yourself. |
|
Thanks for the detailed explanation, I think I know really understand the purpose of the PR |
|
Software developers when they actually have to maintain their software:
Have you considered not supporting GNOME? wlroots is the only good wayland library, if more popular applications only support wlroots then GNOME and KDE will effectively be forced to adopt wlroots instead of their own crap code. |
Did you read my last post? I specifically addressed this:
|
|
My bad I didn't see that, A warning for GNOME users to use XCB? Default to XCB but allow wlroots users to use Wayland? I get why this choice was made but it does hurt users who would prefer a prebuilt binary that supports Wayland, even if via some random config or whatever... Good luck trying to build PCSX2 on my computer 😃 |
Users don't read warnings. They just complain that it's broken.
Not possible, because the decision gets made by Qt before our code runs in the first place. Unless we put a shell script in place, but then self builds versus release builds have behaviour differences, which I'd very much like to avoid.
That's what's happening, at least with the flatpak. As far as I'm aware, flatseal can add additional arguments, so you can override QT_QPA_PLATFORM and add --share=wayland. The code for Wayland is still in the binary, so it'll "just work". AppImage had to have the libs removed because I didn't want to mess around with a custom AppRun script, and as I said above, it'd take precedence over anything user supplied anyway. Edit: I don't really see the issue with PCSX2 running under XWayland. As far as I'm aware, there isn't even a performance hit. |
Good to know I'll try that.
The issue is not PCSX2 but rather my computer. XWayland performs rather poorly on my computer due to some obscure driver bug that's probably not gonna get fixed... Wayland doesn't perform great either but having both just screws things up.
I'm sure there's probably a way to implement the shell script for self builds too? The script itself should be pretty easy through XDG_CURRENT_DESKTOP and XDG_SESSION_TYPE, but you can probably replace the actual executable with a shell script that sets QPA platform according to those variables then runs the application. Doubtless someone could PR that.
True. 😆 GNOME is really good at making the entire software development community hate their guts. |
All this mess for something broken by design. No thanks. I already maintain Linux support, despite not using it on the desktop myself, not adding another thing which can break. |
|
|
AFAIK they're not going to be dropping Xwayland, which is what PCSX2 falls back to. |
|
That's why I made the Manjaro crack at their expense. Just because they aren't dropping Xwayland (yet?) doesn't mean they won't find new, irritating and idiotic ways to cause it to break. With them tentatively dropping Xorg support with the major release following the next big one, Wayland still only half-baked (and their implementation of it being particularly clownshoes): it may be prudent to sketch out additional contingencies. |
|
Like what? The protocol is fundamentally broken. Things like fullscreen switching opening on the correct monitor will never work, because we can't absolute position a window. Qt has tons of WL-specific issues. None of these are in our control. If any distros drop XWayland support, then PCSX2 won't be the only thing affected. Steam, tons of games, etc, won't work either. AFAIK even the browsers haven't switched to native WL-by-default yet. |
|
The immediately available and the most painful (especially file size) option I can think of would be to include Xwayland as a bundled library/dependency for Flatpak/AppImage builds. Then it wouldn't matter what compositor (or what version for that matter) the Host system has or doesn't have as PCSX2 would have its own instance of Xwayland. |
|
Yeah, no, that's definitely not happening. I think dropping XWayland is a bluff. Nobody's actually going to do it, because they know damn well that so many applications simply won't work. Regardless, if it does happen, we'll deal with it then. |
Firefox will default to Wayland when the GNOME camera privacy indicator changes are merged and released. Chrome is Chrome, as always. If you don't want to deal with CSDs, use libdecor, or let QT deal with them; QT has plugins for each relevant Wayland platform, including GNOME. Many other "problems" you listed sound more like you problems, not Wayland problems. |
How is not being able to show a window on the screen at a specific position an "us" problem? At the very least, it's a Qt problem, because we're calling a Qt method to do so, but it's a noop on Wayland because the protocol doesn't support it.
Great, I'll look forward to your pull request, and to solve all the other problems I listed above with Qt. I'd very much like to be absolved of maintaining this broken-by-design platform, so I can spend my time working on fun things, and not fighting the OS, or coming up with ugly workarounds (see #10179 (comment)). Edit: Or, what about NVIDIA crashing when you try to create a swap chain under Wayland? We can't fix these things. All we can do is disable the platform, so that users don't blame and create support headaches for us, for problems outside of our control. Which is exactly what I've done, to ensure a non-broken UX. If you want to suffer, there's the |
This comment was marked as off-topic.
This comment was marked as off-topic.
For those picking up on this as "news", please read the following list:
I_WANT_A_BROKEN_WAYLAND_UIenvironment variable and experience the brokenness for yourself on the AppImage builds, or add the wayland socket to the flatpak.Description of Changes
Disables Wayland, it's super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster.
Until they sort their s**t out, which is unlikely, since there's been very little progress over the last decade, just keep it disabled. For the Flatpaks, users can re-enable it with flatseal if they really want the crappy experience.
Bumps the Flatpak to the KDE/Qt 6.6 runtime, now that it's available.
Bumps the compiler to Clang/LLVM 17, as that's all that's available in 6.6
Removes the host:ro filesystem permission from the PCSX2 flatpak. It's not needed, since we go through portals for adding game directories, and gets rid of the big ass warning about filesystem access on flathub.
NOTE: If you're using third party launchers/frontends with the flatpak, this will break them, since they're probably not using portal paths. Go complain to your launcher/frontend about it, not us, there are ways they can work around it (but I'm not going to do their job for them, since a good number of them are scummy paid products).
Rationale behind Changes
See above.
Suggested Testing Steps
Make sure AppImage and Flatpak still work.