Support us on Patreon
PayPalLess than a week ago, SDL (Simple DirectMedia Layer) developers restarted the discussion regarding whether Wayland should be configured as the preferred over X11, and a PR was made to revert a commit that set Wayland as preferred due to issues with needing fifo-v1 and commit-timing-v1 protocols. This was briefly touched on in our recent SDL 3 article.
Quoting the issue description:
This reverts commit f9f7db4
Wayland has a myriad of unresolved problems regarding surface suspension blocking presentation and the FIFO (vsync) implementation being fundamentally broken leading to reduced GPU-bound performance.
That is not to say "we should fix FIFO in Mesa/other drivers," but rather that it is completely unfixable without an additional protocol, in this case fifo-v11.
Without this protocol, vkQueuePresent or glSwapBuffers must stall for the 'frame' callback after presenting an image. The only reason we can get away with this on SteamOS is because Gamescope implements what is essentially fifo-v1 and we use that there.
The other side is surface suspension -- a very similar issue to the above wrt the frame callback being used in that way and blocking. If the SDL window is obscured, vkQueuePresent will block in FIFO, which games typically do NOT like. This is solved by the combination of fifo-v1 and commit-timing-v1.
There is no advantage to games and average applications preferring Wayland over X11 -- only severe performance and unusability regressions right now.
Thus, we must revert this change until fifo-v1 and commit-timing-v1 are released and at least in a stable release for major compositors.
While SDL tried for the last two years to push Wayland by default and had to revert because there were a number of issues with third-party software (NVIDIA drivers, libwayland event overflow, libdecor not handling plugin load failures, Steam overlay not working with Wayland, etc.).
The situation is promising now because it looks like the pending issues from Wayland are being addressed and the developers are aware and doing their best to solve them. The PR that would revert the Wayland over X11 behaviour again got closed and the merge discarded with a new solution (and a new issue) proposed. Quoting Sam Lantinga:
Thanks for the feedback everyone!
It sounds like the Wayland folks are aware of the issues and are making progress towards addressing them. I'll leave Wayland default for now while they are doing that, so it's easier for people to test and provide them feedback. We will re-evaluate this as we get closer to full release.
@Joshua-Ashton, can you create individual issues that impact this and create a task list in the original merge request report, for tracking?
I'm going to lock this conversation for now so we can focus on development.
And:
Since the performance issues motivating this PR are resolved by the combination of fifo-v1 and commit-timing-v1, let's check for those protocols before using Wayland by default.
@Joshua-Ashton, I'll go ahead and close this PR. Can you open a new one implementing that?
For those following along, this change guarantees that high performance Vulkan applications like games have the best experience by default. Hopefully these protocols will land soon, but either way the user has final control over the backend being used, via the SDL_VIDEO_DRIVER environment variable.
The good news that a mechanism was implemented and instead of dropping Wayland by default in all situations, this will only happen after checking fifo-v1 and commit-timing-v1 protocols.
Feel free to follow-up on that subject by tracking the freshly created issue:
Article taken from GamingOnLinux.com.
fenglengshun Mar 28
It's fine for me now, but man do I have a lot of protocols and portals I'm still waiting to see merged.
pleasereadthemanual Mar 28
Just out of curiosity, I was counting the merge requests for protocol extensions in wayland-protocols today...
There are currently 86 open merge requests (MRs) in wayland-protocols. 4 protocol extensions were merged in the past 7 days, including the long-time linux-drm-syncobj-v1 protocol for explicit sync. 155 MRs have been merged in total (not all are protocols, but most are), and 51 have been closed (either in favor of new protocols or rejected outright).
Of the 86 open MRs, 43 of them were created in the past year. The remaining 43 are more than 1 year old. 14 MRs are between 1-2 years old. 9 MRs are between 2-3 years old. 12 MRs are between 3-4 years old. 8 MRs are between 4-5 years old, including the enormous Color Management protocol (#14), which is actually even older than that because this one predates the gitlab instance.
Did someone mention portals? Certainly not me.
FWIW, Explicit Sync and Color Management are the ones I really care about, and Explicit Sync is finally merged.
Quoting: EikeWhen does SDL have to choose between X and Wayland? If I've got only X running, well, X is it, and if I got Wayland running, I probably wouldn't want SDL to use XWayland? Obviously, it's more complicated, but... why?
That was a "middle ground" the developers found instead of reverting once again the Wayland by Default behavior, checking for fifo-v1 and commit-timing-v1 protocols, and if they are unavailable, fallback to X11 and XWayland.
And the "When does SDL have to choose between X and Wayland?" is more of a philosophical question than a technical one. It's been shown recently that a lot of technologies(distros, libs, softwares) are pushing Wayland by default, or at least using XWayland because if they don't do that, Wayland will not get implemented by other third-parties (cof, cof, Nvidia...)
Wayland is being around for the last 15 years so, need to push it hard or it will never replace the already bloated and hard to maintain X11.
If you are not happy, I think you can still force x11 by exporting the SDL_VIDEO_DRIVER=x11 environment variable.
Last edited by nwildner on 28 March 2024 at 2:53 pm UTC
Linux_Rocks Mar 28
Quoting: EikeWhen does SDL have to choose between X and Wayland? If I've got only X running, well, X is it, and if I got Wayland running, I probably wouldn't want SDL to use XWayland? Obviously, it's more complicated, but... why?
X11 users are not affected.
Under Wayland, a choice has to be made for a Wayland """window""" or an XWayland one and it seems the road it will take will be to check for the new protocol implementation to go for native ones.
Usual SDL_VIDEODRIVER environment variable should allow to override that tho.
Quoting: nwildnerWayland is being around for the last 15 years so, need to push it hard or it will never replace the already bloated and hard to maintain X11.Sounds to me that it doesn't really have a benefit to the end user, otherwise it would have been adopted much faster. I understand it's a necessity for developers, because X11 is dated and the code is in bad shape, but for everyone else it's apparently doing the job just fine.
So to me the question is, is there anything I'm missing out on when using X11? HDR support, maybe? (not that I'd have a HDR-capable display). In short, what's the incentive to switch from a user perspective?
benstor214 Mar 28
Quoting: Purple Library GuyWe're getting to where if someone says "I have an X-box" I won't know if they have a Microsoft console, and old school Linux computer that still uses X, or an appliance dedicated to their Twitter account.It's a set-top box exclusively for pay-tv adult channels.
fenglengshun Mar 28
Quoting: kaimanNew stuff are built on Wayland. If you're fine with x11, sure, just use it. If some of the things happening on Wayland interests you, you can switch. The idea is that we're pushing for Wayland where we can, so that eventually it gets to the point where users who uses x11 can eventually switch to it without noticing many issues. Eventually.Quoting: nwildnerWayland is being around for the last 15 years so, need to push it hard or it will never replace the already bloated and hard to maintain X11.Sounds to me that it doesn't really have a benefit to the end user, otherwise it would have been adopted much faster. I understand it's a necessity for developers, because X11 is dated and the code is in bad shape, but for everyone else it's apparently doing the job just fine.
So to me the question is, is there anything I'm missing out on when using X11? HDR support, maybe? (not that I'd have a HDR-capable display). In short, what's the incentive to switch from a user perspective?
For me, I'm looking forward to the remote desktop portal - input-remapper already made mapping keys on my MMO-style mouse easier, so it was one less reason for me to drag my feet in moving to Wayland and be done with it, but remote desktop portal would genuinely have made me switch because being able to just install a remote desktop app (Rustdesk) from Flathub and it just working is appealing. Though honestly I already can't switch back to x11 because I cannot be arsed to set up touchpad gestures now that KDE Wayland come with it by default.
See more from me