Originally posted by Weasel
View Post
Announcement
Collapse
No announcement yet.
A Session Suspension & Restoration Protocol Proposed For Wayland
Collapse
X
-
Originally posted by tildearrow View Post
What about reopening windows on next login after shutdown? (macOS does this)
Comment
-
Originally posted by Weasel View Post@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.
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.
- Likes 3
Comment
-
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?
Comment
-
Originally posted by ssokolow View Post
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.
Comment
-
Originally posted by starshipeleven View PostNo it is not. To be called "wayland compositor" a compositor has to support Wayland protocol.
Originally posted by starshipeleven View PostYou'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.
Originally posted by starshipeleven View PostThe 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.
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).
Originally posted by starshipeleven View PostPlease leave the security aspects out of this, you have clearly shown in other threads that you should not even speak about basic security practices.
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.
Originally posted by carewolf View PostX11 did no such thing. X11 biggest problem was it ended up a big collection of extensions. Exactly what Wayland is becoming.
Comment
-
Originally posted by dwagner View PostWhy 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?
That said, if you look at the proposal, you'll see that it also adds two other optional modes clients can support:- Using the "session restore" mechanism to seamlessly recover from client or compositor crashes.
- Android-style "transparent suspend and resume" to automatically relieve memory pressure.
Comment
-
Originally posted by Weasel View PostExactly 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).
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.
Originally posted by Weasel View PostAh 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 goes through dbus so pass policykit so as an authentication system.
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.
Originally posted by Weasel View PostWe have a winner. Let's repeat past mistakes, that's for sure showing a superior design.
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.
Comment
-
Originally posted by Weasel View PostI 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.
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.
Comment
Comment