Surface Suspension Protocol Proposed For Wayland

[jrch2k8]

Alexmitter The Wayland core protocol as it was originally envisioned is just unusable because it didn't include support for basic functionality that's needed for user interaction. It was fine for drawing to the screen but as soon as users wanted to interact with their computer, it fell apart. This is what 'broken by design' means.

I.e. the protocol mandates that information going from one wl client to another has to go through the wl server and use a defined protocol. Just hacking around it by using dbus or something else is violating the spec. Hence you need a wayland clipboard copy and paste protocol extension… You want to place a tooltip in a non-awkward position on the screen? new protocol it is! Previewing minimized windows for things like alt+tab? New protocol! Non GLES OpenGL or Vulkan on Wayland? New protocol… Taking screenshots and screen capture… new protocol…

It is so anemic that It can't even properly account for physical monitor sizes (DPI) in single and multi monitor setups. Got a 1080p and a 1440p monitor, both at 24''? The 1440p is "larger" because it has more pixels. Good luck having the user hack around the protocol for fixing scaling while avoiding a net loss of usable screen surface and blurry Xwayland instances, which only fixes single monitor HiDPI use btw.
Just mandate from GUI toolkits that window sizes have to be specified in mm or in multiples of some predefined physical length and let users set a per-screen DPI. Boom, problem solved, perfect multimonitor DPI scaling, w/o artifacts and it wouldn't even need a new protocol or refactoring, had it been thought of in the beginning.

Window manager and compositor being one and the same process is also mandated by the spec, which leads to huge, monolithic processes that can bring down the whole desktop session when an error occurs.

It's a shame that even embedded display stacks like Android's WindowManager and SurfaceFlinger are more feature packed than plain Wayland core. The transition would already be over, had refinement of the Linux display stack started as a fork of these two.

Anyhow, what's your rationale with Vulkan extensions being bad? Game developers don't need them at all for their creations and they're for wrapping and compatibility purposes only. In contrast to Wayland, the Vulkan core spec is actually usable and more than enough to make good looking and well performing games.

Tl;dr core wayland is shit and I admire the devs who have to come up with ideas, extensions and implementations to make it actually viable. Unfortunately this leads to lots of duplicate efforts and slows development for desktop environments but these devs are tough like hell and will eventually poise through it (thanks devs of KDE, Gnome, KwinFT, Sway, AwesomeWM, I3, Enlightenment,… - I know it's not your fault that things are that way)

Sorry for the rant but this had to be said at some point…

Small correction, Wayland core was always functional like Vulkan, the issue you refer is not actually Wayland missed design or anything of the like but desktops environments wanting to make it behave like X11 so they can support both easier to avoid backlashes after the fact.

See it this way, Instead of going the Apple way and focus and redesign the desktops to use Wayland, everyone went the Linux way and suddenly decided Wayland had to support all of X11(as possible) as well because you know, we have to support everything forever.

At least be thankful no one complained enough about Motif or that SUN was not a thing anymore back then or people would still be focused on porting DDE too for Solaris and the mess would be bigger.

Same thing happens with compositors, instead of going full Modern C++/ Wayland / Vulkan and exploit thousand of new ways of handling desktop rendering, low latency, efficient hardware usage, etc. they are focused on OpenGL 3 still because some moron with a 20 year old GPU will cry murder in a forum because he is too cool to use a Centos derivative and too cheap to get even an used decent GPU. Hence we now have to deal with a Frankenstein that kinda works like on X11 but has bugs and kinda runs on Wayland but is not that much better than X11 but with different bugs because the 20+ years codebase they are using is full of hacks and half broken and was designed before threads were a thing but Hey, Linux support everything!!! so be happy

[aufkrawall]

and input latency (also in games) is way better than under Xorg.

I occasionally test gaming on KWin Wayland, while being in touch for this with KWin dev Xaver Hugl, and I think the opposite is still true. Especially since direct scanout currently doesn't work for XWayland (anymore) due to framebuffer modifier situation, which I suppose should affect all others compositors too.

[davibu]

kiffmet
You just described, why X had to die.
Just because it's harder to do specifications, it isn't dumb as you describe. The other way around is the bad thing, just being able to know what other programs are open, just being able to know their framebuffers is the dumb thing.
It would have been easily possible just to do a own fork of Wayland and just implement all the things you need and upstream the changes via specifications simultaneously.
But specified products are always slower than non specified products. Just look at OpenGL vs DirectX OpenGL took ages to specify OpenGL 3 and even Vulkan vs DirectX 12, Vulkan implemented features years later than DirectX 12. Or even HTML where Flash was used because HTML wasn't enough, only years later they introduced <canvas>, <audio> and <video>.

But even after your thinking of the design of Wayland, Windows NT and the Linux kernel must be awful and the MS DOS kernel must be superior, oh the processes can just talk to each other and manipulate each other much simpler than having a IPC API in the kernel.

[d3coder]

Are you sure ? What i see looking at 'https://gitlab.com/kwinft/kwinft' is:

"The KWinFT project consists of the window manager KWinFT and the accompanying but independent libwayland wrapping Qt/C++ library Wrapland."

Yes i am. https://gitlab.com/kwinft/kwinft/-/tree/wlroots-backend

[slowee]

What do you mean? KwinFT uses it and it works perfectly.

Are you sure ? What i see looking at 'https://gitlab.com/kwinft/kwinft' is:

"The KWinFT project consists of the window manager KWinFT and the accompanying but independent libwayland wrapping Qt/C++ library Wrapland."

[kiffmet]

Alexmitter The Wayland core protocol as it was originally envisioned is just unusable because it didn't include support for basic functionality that's needed for user interaction. It was fine for drawing to the screen but as soon as users wanted to interact with their computer, it fell apart. This is what 'broken by design' means.

I.e. the protocol mandates that information going from one wl client to another has to go through the wl server and use a defined protocol. Just hacking around it by using dbus or something else is violating the spec. Hence you need a wayland clipboard copy and paste protocol extension… You want to place a tooltip in a non-awkward position on the screen? new protocol it is! Previewing minimized windows for things like alt+tab? New protocol! Non GLES OpenGL or Vulkan on Wayland? New protocol… Taking screenshots and screen capture… new protocol…

It is so anemic that It can't even properly account for physical monitor sizes (DPI) in single and multi monitor setups. Got a 1080p and a 1440p monitor, both at 24''? The 1440p is "larger" because it has more pixels. Good luck having the user hack around the protocol for fixing scaling while avoiding a net loss of usable screen surface and blurry Xwayland instances, which only fixes single monitor HiDPI use btw.
Just mandate from GUI toolkits that window sizes have to be specified in mm or in multiples of some predefined physical length and let users set a per-screen DPI. Boom, problem solved, perfect multimonitor DPI scaling, w/o artifacts and it wouldn't even need a new protocol or refactoring, had it been thought of in the beginning.

Window manager and compositor being one and the same process is also mandated by the spec, which leads to huge, monolithic processes that can bring down the whole desktop session when an error occurs.

It's a shame that even embedded display stacks like Android's WindowManager and SurfaceFlinger are more feature packed than plain Wayland core. The transition would already be over, had refinement of the Linux display stack started as a fork of these two.

Anyhow, what's your rationale with Vulkan extensions being bad? Game developers don't need them at all for their creations and they're for wrapping and compatibility purposes only. In contrast to Wayland, the Vulkan core spec is actually usable and more than enough to make good looking and well performing games.

Tl;dr core wayland is shit and I admire the devs who have to come up with ideas, extensions and implementations to make it actually viable. Unfortunately this leads to lots of duplicate efforts and slows development for desktop environments but these devs are tough like hell and will eventually poise through it (thanks devs of KDE, Gnome, KwinFT, Sway, AwesomeWM, I3, Enlightenment,… - I know it's not your fault that things are that way)

Sorry for the rant but this had to be said at some point…

[kiffmet]

this look like something gnome dev will refuse to add and KDE will add support after 3 years because they don't see Wayland as a priority and keep focus on x11 or some dead mobile project

i really hate Kwin

You should really give it another try then. Wayland is a first class citizen in KDE now. I.e. The last update rolled out adaptive sync support and input latency (also in games) is way better than under Xorg. Bugs are getting squashed faster than ever. If you dislike Kwin, there also is an independent fork called KwinFT, aiming to deliver a cleaner user experience and minimize latency further. It undergoes a major transition to be wlroots based atm.

[polarathene]

I can see this being used to better inform I/O and memory schedulers/management to prioritize responsiveness of what is active (although if you can't additionally track the age or frequency the currently visible ones and those that have been hidden, it's probably not as effective).

Pretty sure Fedora devs were interested in something like this for adjusting desktop cgroup resources more intelligently. With Gnome and Plasma both adopting that desktop spec to better organize processes within cgroups, it could definitely be a thing?

IIRC there's already a feature that can monitor pressure/activity of resources per cgroup and throttle (less CPU time, slower allocations, adjust swappiness) anything within that slice based on monitoring metrics, even halt the software and prompt the user for a decision.. which is sometimes nicer than an OOM killer playing multiple choice on what to kill.

[d3coder]

But while it is fast in adding new proposed extensions, it is also not anywhere near the completeness as Mutter for the regular not-barebones-tiling desktop.

What do you mean? KwinFT uses it and it works perfectly.

[Alexmitter]

I think Wayland and Vulkan specifications were released too early and without enough feedback, too slow process too. But better late than never.

Both Wayland and Vulkan (also X11, X10...) have a idea concept, and that is usually their first iteration. After that, the protocol does get washed open by needs that pop up later.
For Vulkan, those things were protocols that extended its capability to back API translators like DXVK.
For Wayland, those were tings that extended it beyond the lean display protocol it was designed as.
For X11, that were the dozens of extensions over the year making this 70s design train-wrack doing things you expect in the 2010s

The same applies to any protocol really, its the natural flow when design goals meet reality needs.

I think wlroots should replace libweston ASAP and be used extensively by big projects, including Gnome and KDE. Let their big egos reckon a small project made a very big and amazing effort, for the good of Free/Libre/Open Source Software.

wlroots long since replaced libweston, no doubt about it.
But while it is fast in adding new proposed extensions, it is also not anywhere near the completeness as Mutter for the regular not-barebones-tiling desktop.