Qt 6.6 Wayland Compositor Handoffs Look Promising For More Robust Experience

[MrCooper]

X applications survive just fine when the window manager crashes Not X's fault Wayland mixed the window manager and the graphics server (client) together.

You may not like it, but it means that this is equivalent to X clients surviving a crash of Xorg, not just the window manager. Xorg crashes are a thing, though fortunately it doesn't crash as often these days as it used to, possibly a side benefit of not seeing much feature development anymore.

AFAIK nobody has attempted making X clients survive a Xorg crash (libX11 making it impossible until recently being one reason presumably), thus this is Wayland pulling away from X.

[oiaohm]

AFAIK nobody has attempted making X clients survive a Xorg crash (libX11 making it impossible until recently being one reason presumably), thus this is Wayland pulling away from X.

That not in fact true. XPRA attempt to make X client survive X.org crash.

There is a fundamental X11 protocol vs Wayland protocol difference.

I will do the wayland basics first.
Core design in the Wayland protocol is the compositor can forgot everything and ask the application to send it all new copies of stuff. Totally sane right.

There is a problem with the Wayland solution from the time frame X11 comes from.

X11 protocol application can send item to X11 server to store and receive X11 ID for it. After the application has sent item to X11 server it can free the memory out the client application and if the X11 server loses the item the application can break.

Thinking there is no tidy link between OS process and X11 server application entries welcome to X11 server memory leaks.

https://bugzilla.redhat.com/show_bug.cgi?id=127681#c2

Yes X11 memory leaks going back decades track to the fact X11 server is expected to retain items the client application has told it to keep. This leads to memory leaks in X11 server at times when applications don't correctly tell X11 server to free memory.

Key difference of Wayland protocol is that the Wayland Compositor is perfectly authorized to be totally forgot any item client application has sent to it. This is why making Wayland client reconnect to new compositor is not that complex because 99%(kde developer behind the reconnect value) of what you need to-do to reconnect to new compositor you need to have implemented in wayland client application to handle Wayland compositor saying to client sorry I have forgot what you told me before send me another copy.

XPRA developers with X11 had to end up doing a proxy between X11 server and application to have a copy of data that has been sent to the X11 server and possible forgot by the application. Also XPRA also has to deal with the case that connection between application and server broke it reconnected and the X11 server has not forgot or partly forgot as well.

[carewolf]

You may not like it, but it means that this is equivalent to X clients surviving a crash of Xorg, not just the window manager. Xorg crashes are a thing, though fortunately it doesn't crash as often these days as it used to, possibly a side benefit of not seeing much feature development anymore.

AFAIK nobody has attempted making X clients survive a Xorg crash (libX11 making it impossible until recently being one reason presumably), thus this is Wayland pulling away from X.

Like it? Why wouldn't I like it..

The thing is I know the people who wrote the code and the reason why. They wrote it while working on KWin to make wayland-applications survive restarts of KWin like X-applications does.

You can compare it to surving the display server crashing, but that wasn't the reason it was developed. It was developed to give wayland something it was missing that X11 had.

[oiaohm]

You can compare it to surving the display server crashing, but that wasn't the reason it was developed. It was developed to give wayland something it was missing that X11 had.

This is not exactly true. If you watch the 2021 presentations on this the one thing that comes out is that developer behind this feature was interested in the display server crashing and keeping on going. There is a reason why its called "Addressing Wayland robustness" he also points out that part of it

XDC 2021 | Addressing Wayland robustness | David Edmundson, KDE

https://www.youtube.com/watch?v=fRdnRwPBFBk

3 to 4 min. You will that having application reconnect was impossible to pull of with the way X11 is designed cleanly. Issues with too many server side allocations and so on.

Basically something you cannot do with the X11 protocol that you can do with the wayland protocol.

Yes the early presentations also have items like CRIU that still does not work with X11 as a feature target. So there are a lot of things X11 protocol does not allow you todo that the developer behind this work was attempting to address.

As the developer put it himself. Yes Wayland with the loss of robustness was 1 step back over X11 but this one step back allows 2 steps forwards to something massively more robust once all this stuff is done.

There is small things that have been on going bugs with KDE like you log in and a X11 application manages to attempt to start before users X11 session is up and running now the application dies. This change the Wayland socket can be up before the Wayland compositor is up and any Wayland application supporting compositor reconnect will connect that that socket and wait for the Wayland compositor to be ready to receive traffic.

There is a long list of X11 desktop issues that just don't exist in robust wayland design also that you cannot solve with current X11 design.

[arQon]

How are people this stupid?

Probably because they weren't actually around at the time, so they're ignorant, not stupid. A little deficient in critical thinking too, sure, but I wouldn't quite call it the same thing. When you're in that stage of not knowing anything about anything, the first claim you hear gets to fill that gap, and you accept it as truth regardless of whether it is or not. Then you repeat it in forums like this one, where it lands in the next newbie's head, and the chain continues.

Eventually you reach the current state of things, where the lie has been repeated so many times that a majority of the noisiest posters - usually the same newbies, because they haven't been through this crap a hundred times already - are all echoing it. Since the size of today's post-Ubuntu crowd is far larger than, say, the number of professional developers who used X over dialup decades ago, the truth gets drowned out and the snowball continues. Some of the more insecure ones will occasionally add insults too, to show that their months of experience mean they're not the newest of newbies any more.

At least, that's my guess. I'm confident you're in a better position to know for sure though.

[arQon]

That aside, this is long overdue and very welcome. gnome shell having all the stability of a Windows 95 machine has been an embarrassment for years now, and it's good to see that if a DE is willing to make the effort it can work around the problem of having 3 hours of work wiped out just because an unrelated process shat the bed. Although you can do that at the application level it's an unreasonable amount of effort for any "normal" project to have to go to, and this is a much better place for it.

There's other value here too, especially considering how "in progress" the Wayland DEs are. Just being able to restart the compositor *when you're developing it* is - according to TFA that apparently very posters actually read - a major win for well over a *third* of severe bugs even without getting into how much developer time a full session restart wastes. It also opens up the possibility of tuned compositors for specific cases - fullscreen being the obvious one - which has obvious benefits at both ends of the performance range.

Good stuff. The Wayland ecosystem as a whole needs more progress like this, because we're basically stuck with it at this point regardless.