QtWayland 6.6 Brings Robustness Through Compositor Handoffs

Could someone explain the significance of this for Wayland adoption?<p>As an outsider to the X11 vs. Wayland discussions, my impression has been that the main barriers to simply ditching X11 have been:<p>(1) poor Wayland support in nVidia&#x27;s proprietary drivers<p>(2) Wayland&#x27;s security model making some X11 use cases, e.g. screen recording, difficult or impossible.<p>Does QtWayland 6.6 address either of those (and&#x2F;or some other) barriers?

Could this potentially open up the possibility of implementing a user-level desktop session serialization and restoration feature? Similar to how Emacs handles per-directory sessions.

This reminds me of Arcan where the goal number 1 is robustness, which is probably a good idea given the complexity of GUIs.

&gt; 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.<p>Wasn&#x27;t that just an issue with the Xlib interface? I thought Xcb made everything async.

Finally, save states for Minesweeper.<p>(This is genuinely interesting, I&#x27;m not sure how practical it is, but still very cool.)

[..] Compositors and displays servers are now the same process, doubling the space for errors<p>The wayland security model means the compositor absorbs even more functions from global shortcuts to screencasting and input-method handling [..]<p>Doesnt that mean, Wayland becomes everything that X11 was, just worse? I thought, Wayland was created to break up the monolithic X-Server?