SDL Developers Weigh Reverting Wayland Over X11 For SDL 3.0

[muncrief]

And what were these other candidates?

Anything that didn't require decades of Linux apps to be rewritten, and could actually serve as a drop-in replacement for X11.

[muncrief]

But it is ready and has been so for a long time now.
Some applications like the ones that use SDL will just be using XWayland.

What is the alternative?

No. X11 applications will be supported with XWayland for years to come... As it should btw.

Some of the features of X11 was not well thought out. These features need to go and the applications that use them will not work in the future without some modifications. This is the way it has to be.


Well. Inspite of that, I have now commented on your arguments.

As reality is revealing Wayland is not ready, XWayland does not serve as a drop-in replacement for X11, and blaming the fact that Wayland does not work by claiming X11 was not well thought out does not change that reality. Wayland does not work because it is ill conceived and serving as a drop-in replacement for X11 was not a concern for its developers.

Otherwise everyone would be welcoming, and using it, with open arms and enthusiastic excitement. Instead it has thrown the Linux community into chaos and panic as attempts are made to keep existing applications functional, and even new application development continually reveals its architectural flaws.

[dpeterc]

I didn't say that. And I agree that this is a mistake. The features I wrote about did not include this one.

Thank you for being reasonable about this argument, some Wayland discussions are like talking to people from a parallel universe.

I have re-checked the icon behavior and I have to partially backpedal on my claims, at least on SUSE 15.0 KDE, using Wayland and Xorg.
Actually dynamic setting of icon using _NET_WM_ICON X property works on Wayland using XWayland and correctly displays the dynamic icon on system tray. This works properly without any adaptation of X11 code for Wayland.
Paradoxically my Qt5 application, which supposedly uses Wayland backed and no X11 code, is unable to set its own icon and uses the dreaded yellow W icon.
Funny enough, same application runs fine as Windows binary within Wine and sets its icon properly. Apparently Wine is still using X11 and that still works correctly, even on Wayland.

[HellToupee]

Anything that didn't require decades of Linux apps to be rewritten, and could actually serve as a drop-in replacement for X11.

There is that, its called xwayland, no matter the alternative all the same work would need to be done.

[Blademasterz]

every wayland articles are 99% OOT here lmao

[pracedru]

As reality is revealing Wayland is not ready, XWayland does not serve as a drop-in replacement for X11, and blaming the fact that Wayland does not work by claiming X11 was not well thought out does not change that reality. Wayland does not work because it is ill conceived and serving as a drop-in replacement for X11 was not a concern for its developers.

Otherwise everyone would be welcoming, and using it, with open arms and enthusiastic excitement. Instead it has thrown the Linux community into chaos and panic as attempts are made to keep existing applications functional, and even new application development continually reveals its architectural flaws.

Wayland is not a drop-in replacement of X11. And that is by choice. XWayland is the closest you're going to get, thought it will also break on some things.

[Blademasterz]

I do not care about HDR. I do not even have a screen that supports HDR. But i do have a screen and i want to display my apps on it, which wayland can't. It does not have basic functionality after 16 years of development. WTF?

anyone but you cares XD
btw, which apps?

[woddy]

I do not care about HDR. I do not even have a screen that supports HDR. But i do have a screen and i want to display my apps on it, which wayland can't. It does not have basic functionality after 16 years of development. WTF?

I understand you don't care about HDR, I don't care either, but my apps work great on wayland.
Again, I understand that for some use cases wayland is still not good, which is why all distributions (or almost all) still offer a session with Xorg, but claiming that applications don't work in wayland is an exaggeration unless you refer to particular applications.

[MrCooper]

At this point would it make sense to implement the protocols, but fallback to X11 if those protocols are not implemented (aka you use gnome)?

The protocols haven't landed in wayland-protocols yet, no compositor or client can support them before that happens.

There are WIP mutter implementations of these protocols though (per the wayland-protocols governance process), so no clue where "except GNOME" is coming from. GNOME will most certainly be one of the early adopters of these protocols.

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.

Good question.

Xwayland uses Wayland frame events for synchronizing presentation to the refresh cycle, and a fallback 1 Hz timer for cases when the compositor doesn't send frame events (mostly when the window isn't visible anywhere).

In principle, Mesa could do the same thing itself. The problem is that doing so requires either blocking in Vulkan/GL API calls which aren't supposed to block, or offloading some work to a separate thread (which can't be done reliably for anything which requires committing Wayland surface state).

With Xwayland, all of that is handled by it, so Mesa on the client side doesn't need to deal with it.

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.

Nope, this doesn't require any special-casing for Xwayland in the compositor.

[ssokolow]

Nope, this doesn't require any special-casing for Xwayland in the compositor.

Given what a struggle (still ongoing) it's been to get a means allow Wayland applications to request to position their windows relative to each other, and how X11 applications fundamentally rely on that behaviour for things like menus and tooltips, I'm going to say "citation needed" for rootless XWayland not requiring special-casing.

(For the xdg-pip protocol proposal, there are people who want to build the browser's picture-in-picture window entirely in the compositor, supporting only controls defined in the protocol, to ensure that applications can't abuse it as a means to bypass Wayland's hardline stance on applications choosing how their windows get managed.)