all: use Wayland by default once it is stable/reliable/good enough consistently

[slimsag]

(Thanks for this helpful list from @Clouddef)

Wayland has some fundamental flaws for games and other apps:

• https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
• https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188
• https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18359
• https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99

The goal of this issue is to answer this question: When is wayland good enough for us to use by default?

Today, Mach builds both X11 and Wayland support into the same binary and uses X11 by default. If DISPLAY= is set, then it uses Wayland.

[silversquirl]

The last two are closed merge-requests, which aren't very helpful to track (as they're closed and unlikely to be reopened)
Instead we should track these, which are linked from those last two links, respectively:

• https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/263
• https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/38

I'd like to note, however, that none of these look vital (most have workarounds or are only minor inconveniences) and Wayland is already suitable for use in games.
In fact, the Steam Deck uses gamescope, which is a Wayland compositor, meaning all X11 games run through XWayland on Deck. If Wayland is good enough for Valve, it's good enough for me :)

[silversquirl]

Oh, also, if Wayland is available, it will almost always provide a better user experience than X11, as X11 clients will be running through XWayland, meaning they're hampered by the cumbersome X11 APIs, while also being subject to the restrictions and issues of Wayland applications.

Running under XWayland can't remove any of the restrictions of Wayland, so there's no reason to default to X11 when Wayland is available.

[Cloudef]

Copying from discord:
Indeed defaulting on x11 wont help wayland users. There can be advantages for being an xwayland client rather than native, as compositors implement x11 wm inside them, thus xwayland clients often have more capabilities than native clients (e.g. window positioning), but these really depend on compositor implementation. Anyhow on wayland mach should still default to wayland and accept that there are still issues.

Since mach is getting native wayland backend those above issues all can be avoided by being a "good wayland citizen".
Mach already takes over main, so wayland backend should have similar render loop to JavaScript, that is it registers render callback rather than rendering in a while loop, that way mach wont ever get blocked as it wont try to render when compositor does not allow it.
(this is honestly bad default on wayland side as no other WSI works like this, but i understand why they wanted to do this)

[praschke]

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/38

this issue should have been closed by the suspended toplevel state added to xdg-shell. it relies on compositors exposing v6 (mutter, kwin, hyprland), sway has v2, mir has v5, and gamescope has v3.

connection buffer size control also got merged just yesterday. this also doesn't automatically fix compositors but allows compositors to fix the instant death condition, depending on what they set max connection buffer size to.

[Cloudef]

Seems like the SDL3 PR has accelerated the progress libsdl-org/SDL#9345