We do often include affiliate links to earn us some pennies. See more here.

Less 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.
15 Likes
About the author -
author picture
I'm an enthusiast of Linux on Laptops and Secure Boot related stuff. Playing exclusively on Linux since 2013. Played on Wine on dates that trace back to 2008 (Diablo 2, Lineage 2...). A troubleshooter that used to work with strace and it is now working with Kubernetes...
See more from me
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
17 comments

These are the kind of pressure we need to make Wayland better for more people. It's good enough for some people right now, but for others it's a no-go.

It's fine for me now, but man do I have a lot of protocols and portals I'm still waiting to see merged.
Eike Mar 28
View PC info
  • Supporter Plus
When 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?
Sounds reasonable. Hope the protocol extensions get implemented sometime soon.

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.
nwildner Mar 28
When 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
When can we start calling X11 users The Xtacles?

We'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.
kokoko3k Mar 28
When 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.
kaiman Mar 28
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.
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
View PC info
  • Supporter
We'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.
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.
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?
New 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.

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.
drjoms Mar 28
Does Proton use SDL at all?
Does Proton use SDL at all?
I'm pretty sure many aspect of Steam itself, including the client and the game overlay, uses SDL. I don't know if Proton itself uses it, but I'm pretty sure the thing that interacts with it and the thing it interacts with uses SDL or interacts with SDL themselves.
whizse Mar 28
View PC info
  • Supporter
Does Proton use SDL at all?
Both Wine and Proton uses SDL. Mostly on the controller side for things like force feedback and rumble support. Not for anything that would impact Wayland like window creation or rendering.
nwildner Mar 28
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?

It's a display server. You can't expect bells and whistles on that except really technical stuff that will be used by the DE/WMs with Wayland(lower device latency, standardized interfaces and protocols, better autoconfig, security on app isolation, better modern graphics handling or High-DPI as you've said...).

That's why it is being force-fed. There is no advantage that is immediately "tangible" by the user except it will make things better in the future.

For my personal use, being able to use Waydroid without using the "cage" command on X11 is a plus.


Last edited by nwildner on 28 March 2024 at 9:30 pm UTC
Marlock Apr 4
There is no advantage that is immediately "tangible" by the user except it will make things better in the future.
Wayland fixes a security nightmare that's intrinsic to X11 protocol design.

This has very tangible and immediate effects...

On one hand, it becomes incredibly harder for one app to spy on keyboard strokes, mouse movement and data being displayed on screen by other apps (eg: keyloggers, bank account invasion by password syphoning, malicious overlays, etc)... this is important ASAP for everyone

On the other hand it makes things harder for honest apps that actually need to monitor keystrokes, mouse movement, data displayed on the screen by another app, etc (eg: Screen Recording, youtube streaming, screen sharing during video conference calls, screen reader for accessibility, etc) so those apps broke until Wayland, DEs/WMs and the apps could come up with something they could reasonably agree with that allows legitimate uses without moving backwards in this security improvement

Those details took several years to be ironed out... heck,some wayland devs took years just to acknowledge the legitimacy of some uses, let alone to accept thatwayland itself should help answer those problems... so yeah... 15 years passed.


Last edited by Marlock on 4 April 2024 at 2:32 am UTC
nwildner Apr 5
There is no advantage that is immediately "tangible" by the user except it will make things better in the future.
Wayland fixes a security nightmare that's intrinsic to X11 protocol design.

This has very tangible and immediate effects...

If security was that tangible for end users, no one would be using Windows.

I get your point that X11 is outdated and has a bunch of security or at least design flaws that will lead to security issues in the near future, but we are talking about really end user perspective.
Marlock Apr 5
It's also worth noting that "Wayland took 15 years to get ready" is counted from the baseline spec of the protocol being ready...

...but it took several years of infighting to convince everyone that additional elements had to be included in Wayland instead of delegated to each DE/WM/etc...

...and now that this is pacified, the additional elements are coming along nicely even for things X11 itself didn't handle... but they aren't all finished yet...

...so one could argue that Wayland took 15 years to be defined bit was implemented and used in LTS distro releases even before being fully fleshed out 😁

And it does bring new user-facing things to the table already, they're just around the corner now


And of course any discussions on why X.org is better are doomed because all X.org devs are now working on Wayland instead (IIRC they're the ones that started it), since X.org codebase is a nightmare and nobody wants to touch it with a 10-foot pole... i will refrain from saying they're moot because it helps Wayland become better (as was the case for the extra elements) but they are definitely doomed


Last edited by Marlock on 5 April 2024 at 11:01 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register