Qt 6.6 Wayland Compositor Handoffs Look Promising For More Robust Experience

[Myownfriend]

Runtime switching between different compositors:
https://www.youtube.com/watch?v=JYfzAuRmBjo

I came here specifically to say how awesome this video is lol

[chuckula]

No, the titles says about feature implemented in Qt 6.6 called Wayland Compositor Handoffs, that makes Qt6 Wayland clients not die when the compositor is being killed/crashes. Instead they reconnect to a newly started compositor instance - as the video demonstrates. The feature was actually proposed and PoC was presented quite a lot of time ago, but it wasn't universally praised. GNOME/GTK devs (ahh, because who but them) said they don't want that, it's pointless and instead KDE devs should make their compositor to not crash.

That's kind of like saying memory safe languages are pointless because you should just write your code to have zero memory leaks, buffer overflows, use-after-frees, etc.
Assume Kwin or any similar piece of complex code is "perfect" this feature would still 100% be useful: The compositor could crash for reasons that are 100% beyond the control of the people writing the software given that it interacts heavily with other parts of the graphics stack that can & does have its own bugs.

[mxan]

15 years into Wayland’s existence and finally we won’t lose all our work when the compositor crashes.

Oh wait, only one desktop and only one toolkit can do it, so the entire rest of the Linux app and desktop ecosystem misses out. Turns out, Wayland’s uselessly tiny core protocol wasn’t such a good idea after all, neither was designing the protocol in such a way that mandates putting the display server, window manger and compositor into one giant monolithic process. Reminds me a bit of Windows 98…

In case people forgot, X11 window managers run as just another client like any other application, so they have always been able to be cleanly restarted without your apps even noticing. Many of them can also be completely swapped out for another one during runtime! This is something “ancient” X11 had since the beginning and Wayland is only just catching up on.

Maybe next year, Wayland. Maybe next year.

[Schmellow]

Cool tech, but good luck getting that into GTK lol

[ezst036]

15 years into Wayland’s existence and finally we won’t lose all our work when the compositor crashes.

15 months into KDE's Wayland existence and finally we won’t lose all our work when the compositor crashes.

[mxan]

You think KDE have only been working on Wayland for 15 *months*? KDE first shipped (extremely experimental, barely functioning) Wayland support back in KDE 4.11, back in 2013, the same year GNOME started shipping experimental Wayland sessions. So try about 10 years of both KDE and GNOME working towards transitioning to Wayland, and still 15 years of the protocol’s existence, because this is basic usability stuff that really should’ve been there since the beginning.

[chuckula]

15 years into Wayland’s existence and finally we won’t lose all our work when the compositor crashes.

Oh wait, only one desktop and only one toolkit can do it, so the entire rest of the Linux app and desktop ecosystem misses out. Turns out, Wayland’s uselessly tiny core protocol wasn’t such a good idea after all, neither was designing the protocol in such a way that mandates putting the display server, window manger and compositor into one giant monolithic process. Reminds me a bit of Windows 98…

In case people forgot, X11 window managers run as just another client like any other application, so they have always been able to be cleanly restarted without your apps even noticing. Many of them can also be completely swapped out for another one during runtime! This is something “ancient” X11 had since the beginning and Wayland is only just catching up on.

Maybe next year, Wayland. Maybe next year.

I'm not aware of a system that seamlessly handles X-server crashes with all state preserved, which would be the equivalent of this functionality. I don't really care that in the obsolete world of the X server there needed to be separate compositor that did all the real work and basically bypassed 80-90% of the what the X server was originally designed to do because it didn't work with any GPU from the last 20 years...

[mxan]

Cool tech, but good luck getting that into GTK lol

Noooo you don’t understand, you should just make your compositor Not Crash, because that’s possible when your shell is written in JavaScript, actively encourages modifying its code live during runtime (extensions) because we can’t be bothered coming up with a real, safe API for those, and runs in the same process as the compositor so it’s impossible to restart the shell separately if it does bug out See, it’s your fault the compositor crashed, not our (dumb) design!! — some GNOME developer probably

[Steffo]

15 years into Wayland’s existence and finally we won’t lose all our work when the compositor crashes.
wait, only one desktop and only one toolkit can do it, so the entire rest of the Linux app and desktop ecosystem misses out. Turns out, Wayland’s uselessly tiny core protocol wasn’t such a good idea after all, neither was designing the protocol in such a way that mandates putting the display server, window manger and compositor into one giant monolithic process. Reminds me a bit of Windows 98…

In case people forgot, 11 window managers run as just another client like any other application, so they have always been able to be cleanly restarted without your apps even noticing. Many of them can also be completely swapped out for another one during runtime! This is something “ancient” X11 had since the beginning and Wayland is only just catching up on.

Maybe next year, Wayland. Maybe next year.

Maybe you should read the blog post, because your post is full of BS.
For example: "This post is about Qt, but the world is bigger than that. Not only does this technique work here, but we have pending patches for GTK, SDL and even XWayland, with key parts of SDL merged but disabled already."

Or: "For X11 this was unfixable; clients relied on memory stored by the Xserver, they made synchronous calls that were expected to return values, and multiple clients talked to multple clients.

This was a real problem in my early days of Linux, X11 would lock up frequently enough that most distributions had a shortcut key to restart the server and send you back to the login prompt."

[bug77]

15 years into Wayland’s existence and finally we won’t lose all our work when the compositor crashes.

Oh wait, only one desktop and only one toolkit can do it, so the entire rest of the Linux app and desktop ecosystem misses out. Turns out, Wayland’s uselessly tiny core protocol wasn’t such a good idea after all, neither was designing the protocol in such a way that mandates putting the display server, window manger and compositor into one giant monolithic process. Reminds me a bit of Windows 98…

In case people forgot, X11 window managers run as just another client like any other application, so they have always been able to be cleanly restarted without your apps even noticing. Many of them can also be completely swapped out for another one during runtime! This is something “ancient” X11 had since the beginning and Wayland is only just catching up on.

Maybe next year, Wayland. Maybe next year.

But it works so well in ATMs and car infotainment systems...