QtWayland 6.6 brings robustness through compositor handoffs

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.