A Session Suspension & Restoration Protocol Proposed For Wayland

[TheBlackCat]

Typo:

surfaces and be restored [b]layer[b],

Should be "later", I think

[Michael]

Typo:


Should be "later", I think

Yep thanks.

[ChristianSchaller]

@jrch2k8: Facepalm.


Features like screen capture and apps able to scan other apps are essential. Sure maybe they need to be given "permissions" for "pseudo security reasons", but so what? Add it to the FUCKING PROTOCOL with permissions and all so that ALL apps can interface with ANY wayland compositor in the same, standard, wayland-compliant manner.

I don't care if a compositor implements it or not. As long as it's part of the protocol (specification), it's all good. Screen capture isn't about the fucking compositor but about the application that wants to capture contents of another application and it must have a way to do so -- a standard way, not compositor-specific or toolkit-specific. That's fucking retarded.

Roman Gilg here is doing the right thing, he saw something he felt was missing and are working to resolve it. That is the open source way. If you felt this strongly about it why didn't you do this work years ago so it could have been there from the start? I realize it is less effort to curse and scream in a online discussion than write code, but the thing is that it also achieves a lot less.

[jrch2k8]

@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.

Features like screen capture and apps able to scan other apps are essential. Sure maybe they need to be given "permissions" for "pseudo security reasons", but so what? Add it to the FUCKING PROTOCOL with permissions and all so that ALL apps can interface with ANY wayland compositor in the same, standard, wayland-compliant manner.

I don't care if a compositor implements it or not. As long as it's part of the protocol (specification), it's all good. Screen capture isn't about the fucking compositor but about the application that wants to capture contents of another application and it must have a way to do so -- a standard way, not compositor-specific or toolkit-specific. That's fucking retarded.

It's all about how the app can interface with the wayland compositor -- note, it's ALL about the INTERFACE, not the IMPLEMENTATION.

Ok this time I kinda get your point and sure it would be very nice if that were possible but sadly is done this way simply because no one knew how to implement(as the interfaces I don't mean actual compositor code) them at the beginning, believe it or not is that simple.

Sure, I know many of those features existed on X11 but the problem is X11 internals works absolutely different than Wayland's, so is pretty much only useful to let you know you need to add certain features but the actual implementation(as the interfaces I don't mean actual compositor code) is a completely different monster and require a lot of engineering to reach the point it can be implemented.

Why? simply because the conditions are different, the security model is completely different, the rendering pipeline is completely different, X11 implementation were in many cases nightmarish horribly insecure hacks on top of even worse hacks, not every vendor hardware works the same way and need some abstractions that weren't needed on X11, etc. etc. and more importantly is a completely different model.

X11 was designed to set the standard and the hardware/driver/etc. had to adapt to X11 and had a very high level API but this design model grow exponentially harder to maintain over time and tend to become a hackfest(probably no one hate X11 more than X11 developers)

Wayland on the other hand is a protocol that is designed to connect hardware and developers directly with as minimal abstraction or interference as possible while staying as low level as humanly possible, this model is very hard to get running at first but its maintainability is linear over time and the performance is close to bare metal.

If it helps let me rephrase it this way.

Moving a feature from X11 to Wayland is akin to port an JS library to X86_64 ASM, sure is easy to understand what the JS library does in the big scheme of things but to understand the actual uber specifics of the ASM implementations and techniques needed require a damn lot of work because both system are extremely different, still you wanna to publish a paper on how convert JS to ASM before you understand how that would work in detail expecting an A+, that don't work on reality

[bregma]

This, like everything else related to on-screen rendering, input, and processing, should rightly be moved to pid 1.

[Laser]

This, like everything else related to on-screen rendering, input, and processing, should rightly be moved to pid 1.

In its original design, the X server did so much, it might just have been PID 1 as well.

[Weasel]

Roman Gilg here is doing the right thing, he saw something he felt was missing and are working to resolve it. That is the open source way. If you felt this strongly about it why didn't you do this work years ago so it could have been there from the start? I realize it is less effort to curse and scream in a online discussion than write code, but the thing is that it also achieves a lot less.

I don't particularly care about this feature, but I think it's a good thing to be added, I never criticized it.

Instead, I was just referring to people who -- in past threads about Wayland -- always used the "it's just a protocol" without even understanding what people wanted from it (i.e. these features/extensions to be part of the protocol). For example, if you were to suggest this particular extension in another thread, they'll keep replying "dude it's just a protocol"...

@jrch2k8: Well, I never said it would be easy but considering how popular X11 is (really the only choice before wayland), making big mistakes like this from the get-go is unacceptable to me.

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.

[rastersoft]

All I want is those features to be part of the SPECIFICATION or the protocol. So that any Wayland Compositor will have to implement that and ONLY THAT way to do it, like screen capturing, instead of having to figure it out on its own.

There is a reason to implement this and a lot more as extensions, and not "in the protocol itself" (aka "core protocol"). When X was designed it implemented what, at that moment, was the state of the art in graphics: it had specific commands to draw lines, arcs, fonts... a lot of things. And, of course, it was extensible, which allowed, several years after, to add things like alpha channel and transparency, composition and much more. But that model resulted in a big problem: the original commands for drawing lines and using internal fonts, or palette support, are currently complete obsolete and of no use anymore, but since they are in the core X protocol, that part can't be removed from an X server because they are mandatory. X protocol extensions, on the other hand, can be deprecated and removed when they become obsolete or another extensions supply the same functionality better (https://en.wikipedia.org/wiki/X_Wind...ete_extensions).

When Wayland was being designed, a decision was made to keep the main protocol to the bare minimum, and implement as extensions as many capabilities as possible, to ensure that, if in the future that functionality becomes obsolete, it would be possible to mark them as deprecated and be safely removed. And that's why nearly everything in Wayland are extensions.

But remember that they are as official as the X extensions, which means that those extensions are part of the specification, just like the core. They aren't "proprietary extensions".

[starshipeleven]

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.

I think you are misunderstanding the fact that Wayland isn't desktop-only and not all usecases (embedded for example) give a flying fuck about supporting all desktop features.

So it flat-out can't force support for all desktop features in core Wayland protocol.

Obviously a compositor is free to not implement all Wayland features, but then it's not "fully Wayland compliant".

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

Wayland protocol extensions are optional standards which it can or cannot support.

Even worse, it can make its own screen capturing or whatever other needed feature its own way, even with Wayland,

Everyone is free to hack around their own software however they please anyway, you can't stop that.

An analogy: It's like in real life, you have protocols for stuff and how to behave, but let's say you leave it to the "community" for things you weren't interested in at the beginning on what language to use. Then you have people use spanish, french, chinese, and god knows what else. Just fucking put english in the protocol already, stop delegating it to others.

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.

Sorry but it won't work, most projects involved in this case are very independent, like being independent, and is one of the good things of Linux that they are independent and free to pursue their own goals while working on the common parts together.

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.

[starshipeleven]

An implementation is NOT A STANDARD or specification. A specification is distinct. If GNOME implements features that Wayland lacks as part of its protocol, it cannot be a standard, because GNOME is not a specification, it's an implementation.

You're mixing up things.
Wayland protocol extensions are in fact a specification, a standard. Optional, but a standard nonetheless. Just like OpenGL or Vulkan extensions.

What the developer wants to do here is a protocol extension.

GNOME's screen capture protocol is a GNOME-specific API that is not defined as Wayland protocol extension anywhere and isn't a standard.