Surface Suspension Protocol Proposed For Wayland

[phoronix]

Phoronix: Surface Suspension Protocol Proposed For Wayland

Joshua Ashton who is known for his work on DXVK (formerly D9VK) and related Steam Play / Proton graphics related efforts has submitted a proposal for a Wayland Surface-Suspension protocol...

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Surface-Suspension

[timofonic]

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

Anyway, I hope this inclusive improvement process accelerates exponentially.

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.

[Aryma]

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

[intelfx]

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

This is free software, not some tightly-integrated and tightly-coupled software stack written by a megacorp who can literally throw people at a problem. In a loosely-coupled world, it is literally impossible to solicit any useful feedback without, you guessed it, releasing a specification and encouraging everyone to write an implementation (and then encouraging everyone to use it).

(And before you scream "Red Hat", they do not control nearly everything, despite how much forum fearmongerers and FUD-slingers want you to think.)

[d3coder]

I think Wayland and Vulkan specifications were released too early and without enough feedback, too slow process too.

What's wrong with Vulkan? It works well, designed better than DX12, has excellent tooling.

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

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

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

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

[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…