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.
fenglengshun Mar 28
Quoting: drjomsDoes 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.
Quoting: drjomsDoes 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.
Quoting: kaimanSo 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
Quoting: nwildnerThere 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
Quoting: MarlockQuoting: nwildnerThere 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.
...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
Patreon
PayPal
See more from me