Every release has a killer feature. Qt 6.6 features the opposite – staying alive. This blog post describes work to make Qt clients more robust and seemlessly migrate between compositors, providing resistance against compositor crashes and more.
Qt 6.6 is bringing something to the Linux desktop we haven’t had yet: transparent recovery from display server crashes.
The solution for this? Instead of exiting when the compositor closes, simply…don’t!
If we could connect to a new compositor we just need to send the right amount of information to bring it in sync and notify the application code of any changes to bring this in sync.
For Qt applications all this information is handled in the backend, in the Wayland Qt Platform Abstraction (QPA).
Qt already has to handle screens and input devices being removed, clipboards being revoked and drag and drops cancelled. Supporting a whole reset isn’t introducing any new work, we just have to trigger all of these actions at once, then reconnect to the newly restored compositor and restore our contents.
Applications already have to support all of these events too as well as handle callbacks to redraw buffers. There’s no changes needed at an application code level, it’s all done as transparently as possible.
The benefits here are legion: you can run two different compositors on two different monitors. You can switch compositors at runtime. You can add new features without logging out and back in. Checkpoint restore in userspace, and more. All this made possible by Wayland – X.org cannot do any of these things.
I am waiting for GNOME to implement this so GNOME Shell can survive a crash. Right now you can’t restart GNOME Shell on Wayland (which I have to do whenever I upgrade or add an extension, or just to workaround their memory leaks); not to mention when it crashes I lose all my work, which doesn’t happen too often anymore but does still occur (the Xorg process hasn’t in years for me). I think once that is done and browsers default to Wayland without command-line args (which is going to be general indication they are ready) then I’ll be able to make the switch. Kudos to the Qt and KDE teams for recognizing this problem and coming up with a great solution for it. Now that freedesktop.org people are getting involved in setting more standards, Wayland is moving along a lot more quickly than before, actually solving the problems that still exist and are holding up a lot of people from being able to switch.
…and, once the pending XWayland patches for this land (and, thus, allow me to run anything with patches still pending under XWayland) and they’ve figured out how to adapt things like GPU crash recovery code to applying this to OpenGL, this will solve the number-one thing holding me back from running a KDE Wayland session instead of a KDE X11 session… my preference for staying logged in for months on end under X11 and just using `kwin –restart` if things start to bug out.
(At which point, I’ll start exploring things like how to write a KWin script which uses its “only available to registered scripts” APIs to replace my existing wmctrl/xdotool hackery.)
I don’t see the point in doing tha.
My knowledge on this stuff is rusty, but would this mean you could run on one monitor GameScope in whatever full screen – HDR supporting compositor that uses when exclusive fullscreen, and a full KDE desktop on the other monitor? You might even be able to put Wayland on one screen, and have some kind of legacy X server on another, maybe even driven off an older PCI – 2d accelerated video card from ancient times. Many people who complain about wayland are talking about super niche scenarios – this could give them a way forward (even if that is ill-advised, since xorg is no longer maintained).