3 ms·
This is, just like the article's take, somewhat a misunderstanding of what "wayland" is. A wayland environment basically has 3 "levels": - Wayland core ("wayl
by arghwhat 7y ago
This is, just like the article's take, somewhat a misunderstanding of what "wayland" is.
A wayland environment basically has 3 "levels":
- Wayland core ("wayland")
- Wayland shared protocols ("wayland-protocols")
- Other protocols
Core only concerns itself with nitty-gritty necessities, like how wayland communication actually works. You cannot create a window with wayland alone.
wayland-protocols is where you'd find "xdg-shell", the protocol needed to manage windows on a normal desktop. Protocols here are optional, but are still a collaborative effort.
However, protocol development starts locally, in which case it starts being compositor specific under its own namespace (e.g. "kde"). If it gains traction, other compositors may implement the protocol as is. At some point, a shared protocol draft will be made under one of the "higher" namespaces, like "xdg" or "wp". KDE's idle protocol was widely implemented before a common one was developed from it, for example.
Screen recording is an example of something not yet shared. Wlroots-based compositors like sway fully support it, but details to improve the situation is still under development. An example of such development is to ensure that damage bubbles up to the screen recorder, allowing it to only process screen areas that are reported to have changed.
So, screenshotting is not something implemented in the "upper layers", but something that is currently specific protocols, that will at some point become an (optional) shared protocol.
It is also important to note that Wayland works through a protocol registry, with clients always knowing all protocols available, and using whatever they need if it is supported. GTK and Qt does all this for you, but there is no "If on KDE, do this", rather "I have a protocol that gives me this functionality".
It has always been—and still is—my impression that those considering wayland design "controversial" have simply misunderstood it, such as by thinking that it disallows screenshots and recording. Rather, it is designed to provide control over these things, and to do them right.
I have been using Wayland through sway for the past year. I can confidently say that anything I did under X, Wayland does way better. Multi-DPI, plug-n-play screen support without any hassle, tear-free low-latency rendition, etc. Knowing what is not done yet, I could provoke problems if I wanted to, but nothing interferes with my day-to-day operations.
- Boulth 7y agoExcellent post. Thanks for your in depth insights! Are there any Wayland resources for even more technical information you'd recommend? For the record I use sway for months and can also report that the experience has been great (including hotplugging multiple monitors over Thunderbolt etc.)
- nwah1 7y agoBut the author of this post mentioned a lack of support in apps like Zoom being a dealbreaker. I've also run into incompatibility with TeamViewer. And that is just going to happen whenever these companies get around to it. And if your work requires using such apps, that is just what you need to use. I would prefer some kind of WebRTC-based screensharing solution, but I don't know of any that are preferred and many people just think of WebRTC as a security nightmare, and I haven't seen much momentum with it.
- arghwhat 7y ago"I do not use Wayland because Zoom does not support Pipewire-based recording nor any Wayland screen recording protocols" is a fine although very uninteresting conclusion.