A Session Suspension & Restoration Protocol Proposed For Wayland

[Cape]

I would go ahead and add support for soft/hard shutdown so that either you can't close the sessions if files are opened or files get automatically saved in case of low battery/SNMP trap.

[oiaohm]

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.

There is worse it could be written into the protocol that is not really function because there was not a solid reference implementation to work out if it could work or not.

This is the problem wayland protocol v1.0 really can only include what was in the reference implementation at the time. Including more would have end up with some of the stupidity the old X11 protocol has.

[carewolf]

I would go ahead and add support for soft/hard shutdown so that either you can't close the sessions if files are opened or files get automatically saved in case of low battery/SNMP trap.

Well at least ask, though personally I would prefer forced shutdown after a timeout. The way macOS keeps asking if you are sure for every app before doing what you told it to is infuriating

[RomuloP]

just as a curiosity, what components should be in charge of sharing framebuffers at GPU side between applications? Should rules be enforced by Wayland and so compositors implement the protocol execution? I've read one of the problems with high quality performant screen capture is the fact that a capturing program need to move framebuffer content out of GPU instead of directly being able to make a local copy in GPU and manipulating it there. The discussion in particular was about OBS, where I curiously discovered OBS itself is a compositor according to its developer.

[garegin]

http://www.osnews.com/story/21999/Editorial_X_Could_Learn_a_Lot_from_Vista_Windows_7

[Delgarde]

Look at it this way - specifications generally come about in one of two ways. One, you get a bunch of people sitting around in a committee, designing things based on abstract ideas of how they think things should work. And two, you get a design that's evolved from an implementation, where people spent time learning what works and what doesn't, and then wrote a spec based on their findings.

Guess which one of these generally produces a better outcome? Really, the only people qualified to write a spec are the people who've already done an implementation or two...

[Weasel]

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

But man, I don't really care about KDE or GNOME. There's more DEs than just those 2. I do not want a DE-specific solution to these problems. I find it especially laughable that people think GNOME is a standard just because they use it. Not everyone uses those two damn DEs.

Look, I realize some features have to be based on whether they're possible to be implemented in the first place. But you can do them with X (in its current state). Yes, X is convoluted and full of extensions, but it's old, so you can't blame it. The point is that when designing something new you need to take the good parts from the current X into account. You can blame Wayland though. You can't truly bring something new that lacks features that people actually use. That's unacceptable.


But anyway, the simplest case is that Windows can do it in a standard way, i.e. all apps can be designed around one particular interface and it will just work. Do you want to keep Windows superior to Linux? Because that's what Wayland will do without those into the core protocol. If you can get Wayland to fully support Wine's needs, then at least you know you're on the right track: it means that it can do at least as good as Windows, which should be a MAJOR goal. Windows itself is old as well, so "lack of implementation" is not an excuse. Someone has done it, if you want to compete, you have to do it, or be left behind.

WTF does it make sense to not add something that's implemented in every god damn OS, including Linux with X11. You have implementations, everywhere, to take inspiration from, just not good enough for Wayland so they can add it to the protocol I guess. This is not progress.

Nah, who am I kidding, it's just that they want to push their agenda that "users are morons, let's protect them from themselves, we know best" aka treat them like the mobile-crowd. I know it's not about ability to implement it, it's about them not wanting it in the first place. Pure political reasons.

[oiaohm]

If you can get Wayland to fully support Wine's needs, then at least you know you're on the right track:

Have you looked how wine works under Android. That right it just runs a virtual desktop and be done with it. That is all wine in fact needs. Desktop integration is extra optional features.

From a security point of view windows desktop is garbage. Now try again with examples that work Weasel.

[oiaohm]

Basically, these 3 approaches are currently used:

1. GL -> RAM -> CUDA memory + NVENC -> RAM
2. NVFBC -> NVENC -> RAM (fullscreen only, NVFBC can't do client capture)
3. X -> MIT-SHM (RAM) -> encode (RAM with x264/CUDA GPUmem with nvenc) -> RAM

There is a four method. https://www.phoronix.com/scan.php?pa...KMS-Progress-1
The VKMS is looking to formalise it.

https://github.com/DisplayLink/evdi

Its starts with this DisplayLink evdi work. For prime offload altered areas of screen are already calculated in the video card. This can be used to optimise encode this is at the KMS level inside the kernel.

Forth method is very different.
KMS output mirrored by PRIME to virtual KMS device this gives a stream of damaged rectangles/changes that then can be feed to encoder. No LD_PRELOAD or any other hooks like that. This method does not care about compositor or applications only that output screen is mirror to virtual kms device.

Of course this method in time could possible be extend to wayland output buffers from applications. Reason for needing a unified buffer management system in kernel space.

[Weasel]

Have you looked how wine works under Android. That right it just runs a virtual desktop and be done with it. That is all wine in fact needs. Desktop integration is extra optional features.

So basically what you're saying is that Android functionality is so bad you have to emulate an entire desktop just to be functional is that it? And Wayland should obviously follow such a crap? Right I forgot it's a mobile-muppet design.

From a security point of view windows desktop is garbage. Now try again with examples that work Weasel.

And yet it's used by 90% of people on the desktop. Nobody gives a shit about security when you take away functionality, and usage shows that people are perfectly fine with Windows. When I say nobody cares, I mean 95% of them and more (including macOS and Linux/X11).

Surprisingly, what Benjamin Franklin applies even to computers. They who can give up essential Liberty to obtain a little temporary Safety, deserve neither Liberty nor Safety.

Locking applications in name of security is opposite of freedom. Don't get me wrong, locking them down is good, as long as you have a WAY to bypass the security when needed (e.g. log as root, in traditional models). Wayland gives neither because, of course, how could anyone use their computers in other ways than a shitty mobile phone or tablet? That's Wayland devs' agenda.


Do you know what else is more secure than Wayland is? Plugging off your internet connection. Let's advocate it.