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.

This is a companion discussion topic for the original entry at http://blog.davidedmundson.co.uk/blog/484/
  • Checkpoint restore in userspace, being able to suspend your application to disk and then pick up where you left off like nothing happened. It could never work for X applications, but with wayland reconnect support we can make it work.

This would be great for Plasma Mobile and decrease the energy consumption by a lot.


Energy consumption for sure, but also handling multitasking in memory-constrained situations would be a boon here too. The system could make checkpoints and kill apps not visible on screen when RAM is at a premium. It could also make checkpoints when the battery is at a certain % before a forced shutdown occurs.

Silly question time, because why not: Could Activities be revamped via checkpoints?

  • Different Activities = Different Plasmashell instances
  • The activity switcher checkpoints the running shell instance, then performs a swap. The shell is none the wiser.
  • Plasmashell would internally no longer need to “support” most activities options/settings/switching/logic internally. Per-Activity power profiles and the like might be simplified? (since just the running instance would have control?)
  • Maybe a little info box to some KCMs would be needed; “You have multiple activities on this system. Changes will only apply to this activity.”
  • :frowning: Activities become Wayland-only in P6.
  • :frowning: Kwin transitions would need updating?

The article talks about OpenGL applications being able to be restored if they handle GPU resets. Does this also work for for Vulkan apps? AFAIK Vulkan has its own way of interfacing with display servers (ie. not EGL).

You should edit the wiki on criu.org to talk about Checkpoint/Restore of graphical apps with Wayland. Or at least you should plan to do so when more toolkits support it.

Just wondering about how CRIU in GUI would actually work out in practice. What would happen if say, for example, a game’s state is suspended and resumed on another computer with a different GPU vendor?

I just realized: with checkpoint restore, would the “Stop activity” button be able to completely store an Activity to disk, leaving it without using CPU or RAM, and be restored as it was before for all apps? Could we maybe even make this the default behavior when switching Activities, so it by default always consumes less resources than the simple Activity switching that we currently have?

From what I recall (it’s been a while that I haven’t set up Activities here so I might be wrong), just switching between Activities does not stop apps from using RAM and CPU, stopping an Activity is what does that (only for apps that have support for session restore I believe).