A Session Suspension & Restoration Protocol Proposed For Wayland

[starshipeleven]

However, keep in mind that what really annoyed me when they stated that Wayland is "feature complete" a few weeks/months ago, and basically mostly in maintenance mode, because they really don't care of adding such features to the protocol, they think every user just uses his PC as a tablet where all apps are isolated from each other.

Please leave the security aspects out of this, you have clearly shown in other threads that you should not even speak about basic security practices.

[carewolf]

What about reopening windows on next login after shutdown? (macOS does this)

Exactly that is something macOS has copied from X11, the old Session Management extension, which enabled saving the state of applications and restarting them later with their old state, which is now being converted to Wayland. Like everything else in Wayland, way too late, due to the central team being oblivious to the real world, but better late than never. Looks good so far.

[ssokolow]

@jrch2k8: Facepalm.

I'm not against them adding this, on the contrary, I think features ("extensions") like this should have been there from day 1 of the Wayland protocol.

Do you know why those features had to be there from day 1? Because X11 has them. You want to make a superior protocol (otherwise why bother), then at least look at what's successful about X11, and ditch what's unused or crappy.

Not all Wayland use cases are for desktops. For example, support for a desktop with floating, draggable windows is implemented as a Wayland extension so that people developing smartphones, in-vehicle infotainment consoles, smart TVs, etc. can also write spec-compliant Wayland implementations rather than being encouraged to reinvent the wheel in a way more suited to their needs.

X11 baked all sorts of "state of the art at the time" graphics stuff into the core protocol where it couldn't be removed... it hamstrung the design so much that Apple cooked up an alternative for it called Quartz when they developed OSX and Google cooked up SurfaceFlinger for Android.

[dwagner]

Why would I want to suspend/restore a "session" (whatever GUI-ish stuff that is) when I can already suspend and resume the whole operating system, both to RAM or to persistent storage, including whatever applications are currently running?

Is this a solution searching for a problem?

[carewolf]

Not all Wayland use cases are for desktops. For example, support for a desktop with floating, draggable windows is implemented as a Wayland extension so that people developing smartphones, in-vehicle infotainment consoles, smart TVs, etc. can also write spec-compliant Wayland implementations rather than being encouraged to reinvent the wheel in a way more suited to their needs.

X11 baked all sorts of "state of the art at the time" graphics stuff into the core protocol where it couldn't be removed... it hamstrung the design so much that Apple cooked up an alternative for it called Quartz when they developed OSX and Google cooked up SurfaceFlinger for Android.

X11 did no such thing. X11 biggest problem was it ended up a big collection of extensions. Exactly what Wayland is becoming.

[Weasel]

No it is not. To be called "wayland compositor" a compositor has to support Wayland protocol.

Exactly why it has to be in the core spec to force them to support it. And by "free" I literally meant that, they won't get into legal trouble or otherwise if they don't, but they will be flagged as not compliant by the community (which is currently not the case since it's not in the core protocol).

You're unaware of how development of features happen in a group of very independent parties, and keep thinking a single authority should dictate over everyone.

Nobody forces anyone (developer) to use Wayland though? Originally we had Mir as competitor to Wayland so clearly it was feasible. I don't care who ends up winning (well now it's only wayland, mir no longer competes with it), the point is that one has to win, and dictate everything, so that finally the "GNU/Linux" ecosystem becomes something sensible instead of a mess.

The current situation is similar to OpenGL or Vulkan where each vendor (very independent entity) creates its own "extension" to the spec, but since everyone can implement them the most interesting extensions are eventually adopted by everyone and become de-facto standard or can even end up in the spec.

Nah, that's the reason the ecosystem is so retardedly fragmented in core things like this.

I mean... fragmentation of apps is fine, choice and all... but things that make it a pain for a dev to support all the fragmented "standards" or protocols/features, nah. GNU/Linux's downfall there, sorry.

Yes I'm using GNU/Linux because this is not the kernel's fault at all but the userland so fault is on the "GNU" part (even if it's not all GNU, I'm aware of that... lol).

Please leave the security aspects out of this, you have clearly shown in other threads that you should not even speak about basic security practices.

Ah right, you must be one of those who can't even login as root ever and lets someone else do admin work for him "for security reasons". I mean clearly it's the exact same thing: "disallow features and not allow the user to override them just because I don't use them and I know what security is, not him!"

root is too dangerous after all for muppets.

Remember this isn't about requiring specific permissions to enable the user to do that if he so chooses (choice is bad y'know), it's about not implementing it at all. So no root for you, that's basically what wayland is for apps who want those features.

X11 did no such thing. X11 biggest problem was it ended up a big collection of extensions. Exactly what Wayland is becoming.

We have a winner. Let's repeat past mistakes, that's for sure showing a superior design.

[ssokolow]

Why would I want to suspend/restore a "session" (whatever GUI-ish stuff that is) when I can already suspend and resume the whole operating system, both to RAM or to persistent storage, including whatever applications are currently running?

Is this a solution searching for a problem?

So you can easily get back to what you were doing when your update manager starts nagging you to reboot to apply a kernel update.

That said, if you look at the proposal, you'll see that it also adds two other optional modes clients can support:

1. Using the "session restore" mechanism to seamlessly recover from client or compositor crashes.
2. Android-style "transparent suspend and resume" to automatically relieve memory pressure.

[oiaohm]

Exactly why it has to be in the core spec to force them to support it. And by "free" I literally meant that, they won't get into legal trouble or otherwise if they don't, but they will be flagged as not compliant by the community (which is currently not the case since it's not in the core protocol).

With screen capture is a hard question what protocol should it be in.

DRM protocols with KMS in kernel support damage rectangles so only being informed about what areas have changed on screen instead of having to take snapshot of complete screen. Next the full screen shot system under windows and x11 really don't match current hardware where each screen has its own individual output buffer. So you are doing a lot of image welding and that image welding get really hard when you have two different screens of two different DPI.

Ah right, you must be one of those who can't even login as root ever and lets someone else do admin work for him "for security reasons". I mean clearly it's the exact same thing: "disallow features and not allow the user to override them just because I don't use them and I know what security is, not him!"

root is too dangerous after all for muppets.

Remember this isn't about requiring specific permissions to enable the user to do that if he so chooses (choice is bad y'know), it's about not implementing it at all. So no root for you, that's basically what wayland is for apps who want those features.

This is self should have you asking questions where some of this stuff should be implemented. Wayland contains isolation but was not design to contain a lot of authentication.

https://www.freedesktop.org/wiki/Accessibility/

This goes through dbus so pass policykit so as an authentication system.

https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.ScreenCast

You are also finding screenshot and screencast being implemented under the portal system. This also has authentication system being policykit.

The reality that cpu/gpu usage effective screen capture may have to be implemented at kernel level including in wayland protocol maybe a mistake. Also due to the fact Wayland protocol is design to isolate not authenticate its not really the right place for a lot of things.

Also embedded usage may have not need for screencast or screenshot by applications.

So there is a big question if particularly things should be implemented in wayland protocol at all or if they should be implemented in the likes of "xdg desktop portal" should be implemented wayland/x11 at most ext-ream frame-buffer neutral. Maybe instead of putting these features in the wayland protocol maybe it should be mandatory for a desktop wayland compositor to support "xdg desktop portal" as well as freedesktop accessablity.

We have a winner. Let's repeat past mistakes, that's for sure showing a superior design.

Successful protocol development follows a strict model.

1) Implementation make sure idea can work.
2) Draft Specification.
3) Integration of specification into reference implementation.
4) Option section to Specification
5) Include in future main protocol as required.

Lot of extensions in X11 was horrible. Yes X11 end up with horrible number of extentions. Most never had a draft implementation most never were implemented in the reference implementation before being include in the X11 protocol. So they jumped over the first 3 steps and worse over the first 4 steps. So you need up with a lot of extensions and core protocol in X11 that are impossible to implement to specification.

This is exactly what you have been demanding by saying put it in protocol now. We need to see good implementations and good draft specifications and those good implementation end up in the reference implementation. This process means what ever is in specification can be implemented exactly how it in specification.

KDE developers have a history of following proper process. Gnome ones not so much.


The big thing here we really don't need to have an X11/Wayland/framebuffer... ways of doing lots of things from application point of view. So having some form of general protocol that covers all them that application coders only have to deal with 1 would be the correct way forwards. This also means don't attempt to shove everything to wayland protocol particularly if it really does not own there.

Session Suspension & Restoration Protocol makes sense to be part of wayland protocol. There are many other things that don't really make sense to be part of X11 or wayland protocols that really should be part of accessibility or portals that are interface neutral. Of course these sideline protocols would be nice to be made mandatory to be included in wayland compositors and X11 desktops. Once mandatory enough delete more of the x11 protocol.

[dkasak]

So many posts. So few clues. They way people got worked up about others doing work that they think shouldn't be done ... you'd at least expect them to know what they're talking about.

[Khrundel]

I think you're misunderstanding people who want MORE FEATURES in the protocol (or features as "protocol extensions"). We don't want KDE-specific thing, or GNOME-specific thing, aka "leave it to the compositor" bullshit which leads to fragmentation.

No, you've got everything wrong way. Assuming neither KDE nor GNOME developers are malicious or living at inhabitant island, there is nothing to prevent them to use common solution instead of DE-specifing one, if that solution fits their vision. If they are doing something differently, like CSD vs SSD, that is not because wayland failed to mention this feature but because they think pros of their solution overweights its cons.
Having some standard will not prevent fragmentation at all. Imagine some complicated feature, like screen video capturing, would be
specified within wayland protocol v1.0. Long before first real DE started to implement wayland support. Then, DE1 developers have implemented this feature as specified, without thinking, while DE2 developers will present a better solution. There will be same fragmentation with one party saying they are following standard while another party requesting to deprecate that part of standard and choose their variant.