8 ms·

QtWayland 6.6 Brings Robustness Through Compositor Handoffs

122 points by morceauxdebois 3y ago

jangid 3y ago
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.
- p4bl0 3y ago
  It seems to be what they're going for at KDE: https://floss.social/@kde/111051338968313784 https://floss.social/@kde/111051338968313784 > Plasma developer David Edmundson demonstrates how a desktop using Wayland, Qt6 and KWin can recover from a catastrophic crash as if nothing had happened. > You will lose no data, the video you were watching will not skip a frame, and the contents of your clipboard will remain intact. > The same principles can be applied to jumping from one desktop environment to another, for example, from Plasma to Gnome... > ... And can provide a way to save _the state_ of an application to disk, stopping the app in its tracks and removing it from memory, so that later you can restore it just where you left off.
  - sho_hn 3y ago
    This is more or less what we once dreamed of doing with Activities in KDE 4, but couldn't make it work on X11 - we were banking on the X11 session handling protocols to implement the suspend/restore, only to find that few if any toolkits and apps implemented them properly, and that fixing this wasn't going to be viable due to a lot of spaghetti all over the place. This is partly why Activities ended up feeling somewhat redundant to Virtual Desktops. But if you go back to those early 4.x releases, you will find that the Pause/Unpause buttons etc. on Activities were featured rather more prominently. As David describes in the blog post, things in Wayland are a lot more nicely layered. In part, toolkits have also seen architecture cleanup as a side effect of having to support multiple backends during the transition, and code has become more hackable and modular as a result.
    - JohnFen 3y ago
      Interesting. I played with Activities for a while when they were introduced, but I've never understood what value they provide. I still don't, to be honest. But perhaps it's because they weren't able to provide value?
c-hendricks 3y ago
Finally, save states for Minesweeper. (This is genuinely interesting, I'm not sure how practical it is, but still very cool.)
- saidinesh5 3y ago
  I think the really practical part of this is dealing with out of memory use cases. Iirc he mentioned that in the video too.
CoastalCoder 3y ago
Could someone explain the significance of this for Wayland adoption? As an outsider to the X11 vs. Wayland discussions, my impression has been that the main barriers to simply ditching X11 have been: (1) poor Wayland support in nVidia's proprietary drivers (2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible. Does QtWayland 6.6 address either of those (and/or some other) barriers?
- traverseda 3y ago
  Well KDE has been pretty good about implementing wayland extensions for things like screen recording, accessibility, etc. Gnome has also been implementing extensions but they tend to go off and do their own thing. The main barrier is honestly expecting a bunch of unpaid open source developers to go and re-implement everything. Stuff like barrier/synergy technically has the extensions needed to add in wayland support but it's still all unpaid volunteers. There also used to be some more leeway about protocols and extensions. For a long time now Gnome has been saying "you're either a gnome app or you're not" when they deprecated stuff like tray icons. But there was generally a way back, a way to run your non-gnome app cleanly on Gnome. With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. There are common desktop extensions that Gnome just isn't really interested in developing.
  - tristan957 3y ago
    > unpaid volunteers This is not entirely true. A few GNOME developers within GTK/Mutter/GNOME Shell are paid to work on this kind of work at least part-time. SourceHut also pays Simon Ser to do some Wayland work, whether that is maintaining wayland-protocols or something else. > With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. This is also not true. GNOME has designs for tray icons in their GitLab repo. The thing that is blocking better tray icons in Linux is a lack of interest in finishing the protocol proposal. The ticket hasn't seen much traction in the last couple of months. https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/54 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
PurpleRamen 3y ago
[..] Compositors and displays servers are now the same process, doubling the space for errors The wayland security model means the compositor absorbs even more functions from global shortcuts to screencasting and input-method handling [..] Doesnt that mean, Wayland becomes everything that X11 was, just worse? I thought, Wayland was created to break up the monolithic X-Server?
- sprash 3y ago
  The severely limited scope of Wayland forces all DE vendors to reinvent the wheel and basically recreate their own X11. But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered. Also X11 was never "monolithic" but in reality completely modular. It allows for example to change the window manager or even compositor at runtime without affecting running programs. For this to work your API hast to provide more functionality than your typical Wayland compositor. This is often mistaken for "monolithic" when in fact is actually the complete opposite of monolithic.
  - jauntywundrkind 3y ago
    That's a typical view, but I see it as a lot less monolithic because it's using the kernel to do a huge amount of the things X used to do itself. There's a lot of other concerns (input handling, screen shots, etc cetera) but at the heart Wayland is mostly just a management later for *nix dmabuf's. Mode setting concerns are done by the kernel too. Libwayland mostly uses egl, is my understanding. It invents so much less than X, where-as when X was made, the OS had none of these abstractions to reply on. X was basically the kernel, part 2. Wayland has none of this baggage; in almost all implementations leverages a world of great ready made stuff rather than implementing itself. Source: https://wayland-book.com/surfaces/dmabuf.html https://wayland-book.com/surfaces/dmabuf.html
  - kaba0 3y ago
    > to reinvent the wheel Libraries are a thing > because the APIs are DE/Toolkit specific That’s false in itself, what do you think Wayland protocols are? They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem. > standardization that X11 offered What standardization? A single implementation that does its thing is not a standard, by definition. > Also X11 was never "monolithic" but in reality completely modular But let me guess, you think that systemd is a huge monolith, right? Also, a wm is very trivial compared to the rest, they can easily be a lua extension and that’s it. X is monolithic, because they had to pry printing and shit out of it over years of hard work.
josefx 3y ago
> 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. Wasn't that just an issue with the Xlib interface? I thought Xcb made everything async.
- vidarh 3y ago
  Yeah, very little in the protocol is sync. E.g. when you create a window the client picks the id, and you just go on assuming it will be created until/unless an error arrives. Only things explicitly querying for information is "somewhat" sync, but then too the reply will arrive back with a sequence number, so the client API can just keep returning events and hold on to the replies until you ask for them. X has many warts, but it being synchronous isn't one of them.
  - hulitu 3y ago
    > X has many warts, but it being synchronous isn't one of them. I seem to remember that there was a command line switch to run X (or some clients) in syncronous mode. It was mostly used for debugging.
    - vidarh 3y ago
      Xlib is peculiar in that it doesn't really expose you to the protocol very well. For starters, it doesn't immediately write every request. Partly because it saves bandwidth on slow networks to not send lots of tiny requests that might end up in separate packets. Partly because the Xlib API is pathological in making it hard for you to minimize requests yourself. E.g. a lot of calls to modify graphics contexts can be batched up, but that requires Xlib to not worth requests immediately. So hence there being some value on testing with different flush behaviour. But this is Xlib specific, not really X.
deleted 3y ago
[deleted]
renox 3y ago
This reminds me of Arcan where the goal number 1 is robustness, which is probably a good idea given the complexity of GUIs.
- soupbowl 3y ago
  Arcan has some really cool ideas.
- throwaway1984s 3y ago
  https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp... 6 years ago and no toolkit modifications required.
  - sho_hn 3y ago
    Apples vs. oranges, though. If I read the blog post right, he's demonstrating that he can restart the main Arcan process while an auxiliary process called "waybridge" lives on, which for the Wayland clients is the actual compositor. This still requires the same type of "reconnect and restore" dance, but internal to Arcan-proprietary bits, pushing the problem up one level from the native Wayland exchange. The blog post being discussed here is about handling a crash in "waybridge" instead, so to speak, and having this ability in Wayland itself instead of requiring an additional abstraction and protocol. Arcan can use multiple waybridge instances, e.g. one per client, to get some isolation between the clients (from the post), but it does start to sound a bit heavy perhaps (I don't know much about the inter-Arcan IPC though). Cool stuff, though.
    - akvadrako 3y ago
      That's an irrelevant distinction. In both cases, if there is a crash in the bridging logic, it'll fail. In the QT case, the bridging logic is just living in each app process.

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.

p4bl0 3y ago
It seems to be what they're going for at KDE: https://floss.social/@kde/111051338968313784 https://floss.social/@kde/111051338968313784 > Plasma developer David Edmundson demonstrates how a desktop using Wayland, Qt6 and KWin can recover from a catastrophic crash as if nothing had happened. > You will lose no data, the video you were watching will not skip a frame, and the contents of your clipboard will remain intact. > The same principles can be applied to jumping from one desktop environment to another, for example, from Plasma to Gnome... > ... And can provide a way to save _the state_ of an application to disk, stopping the app in its tracks and removing it from memory, so that later you can restore it just where you left off.
- sho_hn 3y ago
  This is more or less what we once dreamed of doing with Activities in KDE 4, but couldn't make it work on X11 - we were banking on the X11 session handling protocols to implement the suspend/restore, only to find that few if any toolkits and apps implemented them properly, and that fixing this wasn't going to be viable due to a lot of spaghetti all over the place. This is partly why Activities ended up feeling somewhat redundant to Virtual Desktops. But if you go back to those early 4.x releases, you will find that the Pause/Unpause buttons etc. on Activities were featured rather more prominently. As David describes in the blog post, things in Wayland are a lot more nicely layered. In part, toolkits have also seen architecture cleanup as a side effect of having to support multiple backends during the transition, and code has become more hackable and modular as a result.
  - JohnFen 3y ago
    Interesting. I played with Activities for a while when they were introduced, but I've never understood what value they provide. I still don't, to be honest. But perhaps it's because they weren't able to provide value?

c-hendricks 3y ago

Finally, save states for Minesweeper. (This is genuinely interesting, I'm not sure how practical it is, but still very cool.)

saidinesh5 3y ago
I think the really practical part of this is dealing with out of memory use cases. Iirc he mentioned that in the video too.

CoastalCoder 3y ago

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

traverseda 3y ago
Well KDE has been pretty good about implementing wayland extensions for things like screen recording, accessibility, etc. Gnome has also been implementing extensions but they tend to go off and do their own thing. The main barrier is honestly expecting a bunch of unpaid open source developers to go and re-implement everything. Stuff like barrier/synergy technically has the extensions needed to add in wayland support but it's still all unpaid volunteers. There also used to be some more leeway about protocols and extensions. For a long time now Gnome has been saying "you're either a gnome app or you're not" when they deprecated stuff like tray icons. But there was generally a way back, a way to run your non-gnome app cleanly on Gnome. With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. There are common desktop extensions that Gnome just isn't really interested in developing.
- tristan957 3y ago
  > unpaid volunteers This is not entirely true. A few GNOME developers within GTK/Mutter/GNOME Shell are paid to work on this kind of work at least part-time. SourceHut also pays Simon Ser to do some Wayland work, whether that is maintaining wayland-protocols or something else. > With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. This is also not true. GNOME has designs for tray icons in their GitLab repo. The thing that is blocking better tray icons in Linux is a lack of interest in finishing the protocol proposal. The ticket hasn't seen much traction in the last couple of months. https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/54 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...

PurpleRamen 3y ago

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

sprash 3y ago
The severely limited scope of Wayland forces all DE vendors to reinvent the wheel and basically recreate their own X11. But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered. Also X11 was never "monolithic" but in reality completely modular. It allows for example to change the window manager or even compositor at runtime without affecting running programs. For this to work your API hast to provide more functionality than your typical Wayland compositor. This is often mistaken for "monolithic" when in fact is actually the complete opposite of monolithic.
- jauntywundrkind 3y ago
  That's a typical view, but I see it as a lot less monolithic because it's using the kernel to do a huge amount of the things X used to do itself. There's a lot of other concerns (input handling, screen shots, etc cetera) but at the heart Wayland is mostly just a management later for *nix dmabuf's. Mode setting concerns are done by the kernel too. Libwayland mostly uses egl, is my understanding. It invents so much less than X, where-as when X was made, the OS had none of these abstractions to reply on. X was basically the kernel, part 2. Wayland has none of this baggage; in almost all implementations leverages a world of great ready made stuff rather than implementing itself. Source: https://wayland-book.com/surfaces/dmabuf.html https://wayland-book.com/surfaces/dmabuf.html
- kaba0 3y ago
  > to reinvent the wheel Libraries are a thing > because the APIs are DE/Toolkit specific That’s false in itself, what do you think Wayland protocols are? They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem. > standardization that X11 offered What standardization? A single implementation that does its thing is not a standard, by definition. > Also X11 was never "monolithic" but in reality completely modular But let me guess, you think that systemd is a huge monolith, right? Also, a wm is very trivial compared to the rest, they can easily be a lua extension and that’s it. X is monolithic, because they had to pry printing and shit out of it over years of hard work.

josefx 3y ago

> 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. Wasn't that just an issue with the Xlib interface? I thought Xcb made everything async.

vidarh 3y ago
Yeah, very little in the protocol is sync. E.g. when you create a window the client picks the id, and you just go on assuming it will be created until/unless an error arrives. Only things explicitly querying for information is "somewhat" sync, but then too the reply will arrive back with a sequence number, so the client API can just keep returning events and hold on to the replies until you ask for them. X has many warts, but it being synchronous isn't one of them.
- hulitu 3y ago
  > X has many warts, but it being synchronous isn't one of them. I seem to remember that there was a command line switch to run X (or some clients) in syncronous mode. It was mostly used for debugging.
  - vidarh 3y ago
    Xlib is peculiar in that it doesn't really expose you to the protocol very well. For starters, it doesn't immediately write every request. Partly because it saves bandwidth on slow networks to not send lots of tiny requests that might end up in separate packets. Partly because the Xlib API is pathological in making it hard for you to minimize requests yourself. E.g. a lot of calls to modify graphics contexts can be batched up, but that requires Xlib to not worth requests immediately. So hence there being some value on testing with different flush behaviour. But this is Xlib specific, not really X.

deleted 3y ago

[deleted]

renox 3y ago

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

soupbowl 3y ago
Arcan has some really cool ideas.
throwaway1984s 3y ago
https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp... 6 years ago and no toolkit modifications required.
- sho_hn 3y ago
  Apples vs. oranges, though. If I read the blog post right, he's demonstrating that he can restart the main Arcan process while an auxiliary process called "waybridge" lives on, which for the Wayland clients is the actual compositor. This still requires the same type of "reconnect and restore" dance, but internal to Arcan-proprietary bits, pushing the problem up one level from the native Wayland exchange. The blog post being discussed here is about handling a crash in "waybridge" instead, so to speak, and having this ability in Wayland itself instead of requiring an additional abstraction and protocol. Arcan can use multiple waybridge instances, e.g. one per client, to get some isolation between the clients (from the post), but it does start to sound a bit heavy perhaps (I don't know much about the inter-Arcan IPC though). Cool stuff, though.
  - akvadrako 3y ago
    That's an irrelevant distinction. In both cases, if there is a crash in the bridging logic, it'll fail. In the QT case, the bridging logic is just living in each app process.