SDL Developers Weigh Reverting Wayland Over X11 For SDL 3.0

[TemplarGR]

My gripe with Wayland replacing X11 is that Wayland wasn't , or isn't, a complete solution even theoretically. We're getting there, but it has taken a long, long time. Had "someone" actually planned a complete ecosystem instead of having small islands of software, we would have had a much easier transition.

According to https://en.m.wikipedia.org/wiki/X_Window_System the X11 protocol was finalised 1987, three years after initial release.
Wayland had its initial release 15 years ago, and its ecosystem is still not feature complete, comparatively.

There are multiple reasons for this:

1) Graphic stacks are far more advanced these days than in 1987, therefore there is a lot more work to be done at all stages of the stack

2) Back then there wasn't an alternative. It was either X11 or nothing. So everyone hopped on board X11

[andresdju]

My gripe with Wayland replacing X11 is that Wayland wasn't , or isn't, a complete solution even theoretically. We're getting there, but it has taken a long, long time.

For X it took nearly 20 years to have a semi-modern system. Wayland is more modern from the very beginning.

According to https://en.m.wikipedia.org/wiki/X_Window_System the X11 protocol was finalised 1987, three years after initial release.

What the link you provide says is that the X11 protocol that was published and released in 1987 was finalized in August 1986. But what was released then is not the final protocol of X Window System you are using now. After that a lot of new releases have been made, it doesn't matter if they are still called X11 instead of X12, X13 and so on. Current software doesn't use most of the old protocol and instead use extensions developed during the 90's and 2000's. Since around 2010, X is mostly in maintenance mode.

To see how much X11 has evolved and how much of the old protocol is only for old applications compatibility, you can read https://www.x.org/wiki/guide/client-ecosystem/.

It is true that Wayland still lacks a few features that X have, but it also happens the other way around.

[johanb]

There's also some suggestions that the fifo-v1 and commit-timing-v1 protocols should be checked for in deciding the Wayland support as opposed to a complete revert.

What's the flaw with doing it this way? Is it only that those protocols are still in staging?

[Lysius]

How can XWayland get around those problems without the proposed new protocols? It obviously must have some way, otherwise using X11 (via XWayland) as default over native Wayland would not have any advantage on Wayland systems.

[ssokolow]

one step forwards, one step back. one step forwards, one step back. one step forwards, one step back. one step forwards, one step back.

The Wayland dance!

[Vistaus]

Xorg trolls, do not celebrate yet.... Issues like this are GOOD, because they lead to the implementation of new protocols to solve them.... Eventually Wayland will be a rock solid default for SDL 3.0 . No matter how much you spread FUD and troll against Wayland, Xorg is dead. Deal with it.

Problem is that some Wayland fanboys keep trying to convince us that Wayland is a full replacement and can do everything that X11 can. Issues like this are good, but also show that some people are too much of a fanboy.

[ssokolow]

How can XWayland get around those problems without the proposed new protocols? It obviously must have some way, otherwise using X11 (via XWayland) as default over native Wayland would not have any advantage on Wayland systems.

The compositor developers special-case it. The relevant APIs aren't available to other processes and, if you discover a way to get access to them, it's considered a hole/vulnerability to be patched.

[ssokolow]

There are multiple reasons for this:

1) Graphic stacks are far more advanced these days than in 1987, therefore there is a lot more work to be done at all stages of the stack

2) Back then there wasn't an alternative. It was either X11 or nothing. So everyone hopped on board X11

3) Design-by-committee hell, such as the back-and-forth currently going on over things like whether it's legitimate to want your non-MDI multi-window application to be able to request that its subwindows be positioned relative to each other, whether "the Wayland way or the highway" will just result in such applications refusing to port from X11, how over-engineered each Wayland compositor would become with the "un-abuse-able design" (basically the WM equivalent to how people were proposing basically implementing an entire restricted-function widget toolkit inside the compositor so that xdg-pip could present an API too high-level to be abused to create non-PiP windows for application-defined window management behaviour), and whether proposed "the Wayland way" solutions would actually be immune or whether they'd just result in StackOverflow filling up with "if you do this dance, it'll trick compositor X to laying out the windows the way you want" answers. (eg. Stuff like using temporary windows as spacers to achieve absolute positioning using left-of/right-of/above/below-type positioning.)

(Basically, there's a lot of second system effect at play but, of the "XWayland exists for people who don't like it, so we can dictate terms for native Wayland APIs"-themed variety. Instead of being over-engineered feature-wise, Wayland is over-engineered in the "We can anticipate and prevent all 'abuses of the APIs'. We can avoid repeating the mistakes of X11 or C++ or other such things if we just refuse to accept any designs we're less than certain are a good idea." sort of way.)

[Monsterovich]

Xorg trolls, do not celebrate yet.... Issues like this are GOOD, because they lead to the implementation of new protocols to solve them.... Eventually Wayland will be a rock solid default for SDL 3.0 . No matter how much you spread FUD and troll against Wayland, Xorg is dead. Deal with it.

So you will need protocols for something that already worked by default in Xorg for decades? And these protocols will be "staging" how much? 10 years? Also those protocols will have to be implemented individually in each DE-sever like everything else, and then it will *probably* turn out that GNOME or some DE will make their own protocols because they have the NIH-syndrome.

Typical Waytrash.

[Monsterovich]

Do you know when X11 will get HDR support? I mean, its out for 40 years now.

HDR is not needed on a desktop. If it was, it would have been done by now.

A decent HDR monitor now costs from about $1000 on the market. Not everyone even has a monitor that supports VRR (I do and it works fine in Xorg).