Surface Suspension Protocol Proposed For Wayland

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

[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

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

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

[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

[timofonic]

I think Vulkan evolves considerably faster than Wayland these days, but not in enough pace IMHO.

Wayland needs a core implementation, massive but coherent and intelligent code sharing. I think something based on wlroots and keep progressing would be interesting to have, then remove code duplication between at least major WMs and DEs. Of course, maybe a better alternative may happen. But this madness of code duplications is a total and utter technological suicide.

Vulkan should absorb OpenCL and other APIs, being the sane and best alternative to DirectX. SDL is just a ducktape and buggy alternative, not so serious. And evolve FAST too, a lot more than now.

I agree modern desktop should kill OpenGL and go the Vulkan route, then contribute to make Vulkan the best and stronger standard.

Current situation is a bad joke. A bunch of brave developers must propose alternatives and start a strong discussion about this.

[jrch2k8]

I think Vulkan evolves considerably faster than Wayland these days, but not in enough pace IMHO.

Wayland needs a core implementation, massive but coherent and intelligent code sharing. I think something based on wlroots and keep progressing would be interesting to have, then remove code duplication between at least major WMs and DEs. Of course, maybe a better alternative may happen. But this madness of code duplications is a total and utter technological suicide.

Vulkan should absorb OpenCL and other APIs, being the sane and best alternative to DirectX. SDL is just a ducktape and buggy alternative, not so serious. And evolve FAST too, a lot more than now.

I agree modern desktop should kill OpenGL and go the Vulkan route, then contribute to make Vulkan the best and stronger standard.

Current situation is a bad joke. A bunch of brave developers must propose alternatives and start a strong discussion about this.

I agree that vulkan should absorb OpenCL functionality with caveats(like new syntax for example) but Wayland is fine as it is, the problem lie on the compositors and toolkits not Wayland and as long as they insist on supporting both X11 and Wayland forever, Wayland will get more and more extension and more and more libraries and more and more compositor because they are not migrating to Wayland but converting Wayland into X11 so they can keep using the old codebase as much as possible which is where the real issue is.

Remember when you have to support several implementation you have to put a ceiling that matches the lowest common denominator that in this case is what little X11 supports compared to Wayland, so basically what you have now is not missing Wayland features(except very few extensions) but a layer to make Wayland into WX11 as much as possible

[murraytony]

Wayland was designed to be extended to add desired features to be implemented by compositors. This way extensions can be deprecated and removed when they are no longer needed and are only added when needed. The reason we are still seeing extensions added regularly is because Wayland compositors are still maturing. Baking functionality into the base system was a mistake X11 made, the designers chose not to repeat it.

[Weasel]

LMFAO so what happened with the pseudo security bullshit? What happened with the privacy concerns?!?? Oh noes, knowing when a window/surface is completely occluded can be a privacy leak!!! Tragic!!!!

Nuke this suggestion, it's against Wayland's idiocy.

If this suggestion goes through, might as well allow absolute positioning to be a thing, so it can finally start looking like a semi-decent protocol. The bullshit reasons made up around Wayland's arbitrary limitations are laughable at this point. That's what happens when people value their ego more than logic I guess.

Tl;dr core wayland is shit

Amen.

[dpeterc]

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

So you are saying X11 is a 70s design train-wrack, because it planned for extensions by design and has grown by extensions for 30+ years. In my book, that is good design.
And Wayland is lean design, which had extensions forced onto it, because people expected the same functionality which they had on X11?
Which is basic UI stuff like drag and drop, cut and paste, popups opening at the correct place, network transparency, multi-monitor support, screen recording...
I wonder which other miracles will the fresh and lean 2020 design will bring us.

FYI, X11 was released in October 1987, gained popularity in the nineties, so it is hardly a 70s design. Unix is 70s design. Now replace that, just because it is old design.