Is this true about wayland?

xyrgug · 2024-03-09 06:56:36

In a very heated discussion on another forum there posted a picture that says wayland is not as simplistic as they try to make it out to be.
Could you tell if what is in this picture is true?

https://imgur.com/a/4g22ll2

fullscreen
https://i.imgur.com/AIvLISX.png

Last edited by xyrgug (2024-03-09 06:59:10)

seth · 2024-03-09 08:54:31

1. off "heated discussion on another forum" - post the link for proper context.

Both claims are true, the difference between the upper and the lower are that the lowe accounts for
1. the necessety to support X11 clients (what will not go away for a looooooooooooong time, but there're eg. nested X11 servers for windows, mac OS and, w/ Xephyr, even X11 itself)
2. the fragmentation of the wayland compositors. The core protocol was designed to be as secure as possible, then people figured that security and usability are actually a trade-off, so they started expanding the protocol and because the various teams couldn't even ever get to stick to the NETWM spec that was drafted for X11 in a drunken moment of sobriety, the various extensions are incompatible.

There're fundamentally 3 kinds of wayland: KDE, Gnome and wlroots. And wlroots (sway, hyprland, …) then splits into various, on details incomaptible, subflavors.
For X11 there's (mainly) Xorg, the other implementations are so insignificant that they try to be compatible with it.

Here's a rant from an artix guy, it's generally accurate: https://dudemanguy.github.io/blog/posts … -xorg.html

The problem isn't so much wayland (as protocol) or the idea to have a display server that's not loaded w/ legacy stuff that nobody uses, but the kindergarten sandbox-wars.

As for wayland itself, users tend to focus on "but it's tear free and smooth" (don't say butter, I hate butter), but you could have had that in optional extension to X11 as well (afaiu) DRI3 started out this way.
The two real main benefits are better client isolation (which lead to the sandbox wars, because every compositor undermines that in different ways) and input redirection which
a) comes at the price of geographic blindness, clients don't know and can't control their position on screen - everything has to be a feature of the compositor, what's dumb and actually not necessary
and
b) is criminally underused in its potential, you're effectively dealing w/ WMs that stick to X11 rules for no reason (see eg. https://arcan-fe.com/2021/04/12/introducing-pipeworld/ for what *could* be possible with that)

tl;dr - the problem isn't wayland but the kindergarten around that and the posted image illustrates that correctly.

xyrgug · 2024-03-09 09:10:55

seth wrote:

1. off "heated discussion on another forum" - post the link for proper context.

All right but you asked for it.

https://boards.4chan.org/g/thread/99309 … ke-wayland

seth · 2024-03-09 09:28:46

Ok, every discusion on 4chan is heated. It's mostly trolls trolling each other.
I'd not freak out about that.

The wayland universe is currently fragmented, there's no denying that.
If the kids don't get past that, it'll go down like the dozen or so other attempts to replace X11.
And then life goes on.

Trilby · 2024-03-09 14:15:31

I think the broad point they are making is absolutely true, but the visual is completely wrong. That visual (in the lower right) is portraying many compositors running at the same time which is just completely absurd.

But it also completely misses all the additional protocol extensions needed to do *anything* a desktop user would expect to do on their system. The core wayland protocol doesn't even allow for client windows to request to be "maximized", "minimized", or moved around. The xdg-shell protocol is now so tightly integrated that these actions are well supported, but task bars, docks, etc are not at all supported by any universal protocols.

Wayland was sold on the idea of being "simpler" due to X11 requiring protocol extensions for compositing / transparency. This claim is true. It is also true that wayland doesn't need protocol extensions for compositing / transparency. But it needs protocol extensions for *everything* else. Many good X11 window managers can do fine with just the base X11 protocol. Even most of the big DEs may only use one extension: Xrender. But for any wayland compositor to function at all, it may need to use a dozen protocol extensions, most of which are not at all standardized resulting in some client programs only running on certain compositors and not others.

An example is that any bar / dock type "window" in wayland can be written to work with wlroots based compositors, OR QCompositor-based ones (e.g., KDE), OR gnome. The KDE protocol and the wlroots protocols have converged and seem to be compatible now - but Gnome is still completely separate. And again, this is just for making what X11 called override-redirect windows that are not "managed". Lots of other behaviors taken for granted in X11 are simply not possible in wayland without yet other protocols. If a taskbar wants to list the titles of open windows there is no way for it to get that information except through a non-standard protocol that may or may not be supported by different compositors.

So in reality, there it can range from difficult to impossible to write a true "wayland taskbar". Instead most software presented as "wayland taskbars" are really "wlroots taskbars". And this pattern holds true for countless other types of utilities.

X11 did hundreds of things well, and a couple things really poorly. Wayland stepped in and figured out how to do those couple things really really well, but it just doesn't do those hundreds of other things at all (not even poorly, it just cant do them at all).

EDIT: to touch on the security points mentioned, it's important to note that there is (almost) always a trade-off between security and features. Wayland indeed does isolate clients far better than X11 does. But it turns out, users really don't want clients isolated from each other as it prevents us from doing all the things we want to do with our computers! We want a taskbar or task-switcher to be able to list the other active clients. We want to be able to copy / move data from one client to another. We want clients to be able to be (or request to be) fullscreened. Taken to it's logical extreme, a better way to achieve security and client isolation is simply to not turn your computer on. But if we're turning our computers on, we probably want them to do something ... and wayland is really bad at doing most things we want. When protocol extensions are added on to make these things possible, they generally end up being even less secure than X11 was.

Last edited by Trilby (2024-03-09 14:25:14)

xyrgug · 2024-03-09 15:53:41

What future do you see for linux desktop with wayland?
Almost all distros make wayland by default.
What's next? Will the ecosystem developers be able to somehow adapt wayland to the needs of the users or I dunno bend the wayland developers to make it more user friendly?

Last edited by xyrgug (2024-03-09 15:54:20)

Trilby · 2024-03-09 16:00:08

xyrgug wrote:

Will the ecosystem developers be able to somehow adapt wayland to the needs of the users or I dunno bend the wayland developers to make it more user friendly?

Who do you think "wayland developers" are? The team that developed the core wayland protocol is almost certainly not going to scrap it and start again.

But the "ecosystem developers" assuming this just means everyone else writing software are adapting. But they're all adapting individually. So wayland is basically the wild west right now: everyone writes their own protocol for their compositor. As such it is near meaningless to talk about "wayland client" software: there is "gnome client" software and "kde client" software, and "wlroots client" software (or in worse cases hyrpland client software or weston client software if said software uses a protocol specific to a single compositor) - but aside from very simple programs, there is no generic "wayland client" software.

There are, of course, desires from almost all parties to converge / cooperate (not really from gnome it seems, but they can go gnome-themselves). KDE and wlroots teams are working well together and getting some convergence (hence their individual layer-shell protocols being able to interoperate well at present). But wayland protocols are currently facing this. I'm sure that will change at some point. Perhaps some consortium will step up and do something comparable to what the ICCCM or EWMH did for X11. But this just hasn't happened yet at a meaningful scale (we do have the xdg-shell protocol which is a good example of how this can work well: there's a broad consensus supporting this protocol extension).

Last edited by Trilby (2024-03-09 16:12:52)

seth · 2024-03-09 16:01:07

"Prediction is difficult- particularly when it involves the future."
--- Mark Twain

The linux desktop is niche, fragmenting that is gonna lead to certain death.
Alternatives are
- everybody returns to X11
- wayland gets its act together
- we all use OpenAndroid™ or something like that

mesaprotector · 2024-03-13 00:20:09

Arcan exists if you want an alternative... even though it's been a single guy developing it for the past seven years or so.

I see myself switching to Wayland eventually. I haven't yet because I use Openbox, and there just hasn't been much effort to develop a floating WM for Wayland - everyone is either moving towards tiling with i3/hyprland or full DEs. I know waybox/labwc exist but their communities are still tiny. I also doubt all the keyboard shortcuts I've put into Openbox will still work...

If I had to guess, I'd say wlroots will eventually become the default - and Wayland + wlroots will just be the new Xorg. Probably an improvement on X11? But who knows.

Last edited by mesaprotector (2024-03-13 00:20:59)

leessmin · 2024-04-27 06:02:41

My nvidia's experience with x-wayland's rendering is not as good as it could be, resulting in having to use x11, but I do like the touchpad functionality on wayland. But because of the rendering problem I have to continue to use x11, if nvidia still can't support wayland well in the future, I think I can consider using amd GPU!

seth · 2024-04-27 07:46:17

https://www.phoronix.com/news/Explicit- … Wayland-Go

leessmin · 2024-04-27 12:36:31

This sounds great, hopefully the day will come soon

d.ALT · 2024-06-14 09:02:47

Trilby wrote:

We want to be able to copy / move data from one client to another

Yeah, just like copy-paste from Firefox to (eg.:) Konsole...

I'm not a tech-user or a developer neither (and lately most of my free time I'm spending it outside the Linux "world"), but one thing for sure feels "wrong" to me: they're working on $PROTOCOL from 2008 and still - nowadays - $PROTOCOL has not yet managed to fully replace $SERVER; now, you could tell me what you want about Big Players \ Big Contributors actually not contributiong and not helping $PROTOCOL's development, but this is still - to me - a big no-no: 14years of development without a strong and wide adoption.

Trilby · 2024-06-14 12:12:49

The problem is the Wayland protocol was never even intended to replace X11. Wayland did everything it was intended to do pretty quickly. But then everyone looked at it and thought "well, that's pretty useless; I mean, it's pretty, but useless" - which really should have had them go back to the drawing board, but instead we now have years worth of duct-tape and varnish over a fundamentally inadequate protocol.

Case-in-point of inadequate by design: there is no way to send a 64-bit numerical value over the wayland protocol. Period. You cannot send a pointer to a window / surface, nor a PID, nor any other of a number of useful bits of data to exchange. You can get this data transferred by either chunking it into an array of 32-bit integers and then reassembling it on the other end, but it turns out this is much harder than just creating a separate socket and sending the fd over the prodocol and having the other end read the pointers, pids, etc from the additional socket.

The madness of all this once led me to try to abuse the file-descriptor field to carry arbitrary 64-bit values - but that failed completely. While the fd field takes up 64-bits of space, the protocol doesn't allow you to use them all - so true 64-bit values were mangled in transit.

But hey, maybe it's great on 32-bit systems. That's forward thinking for you.

Last edited by Trilby (2024-06-14 12:14:22)

Arch Linux

#1 2024-03-09 06:56:36

Is this true about wayland?

#2 2024-03-09 08:54:31

Re: Is this true about wayland?

#3 2024-03-09 09:10:55

Re: Is this true about wayland?

#4 2024-03-09 09:28:46

Re: Is this true about wayland?

#5 2024-03-09 14:15:31

Re: Is this true about wayland?

#6 2024-03-09 15:53:41

Re: Is this true about wayland?

#7 2024-03-09 16:00:08

Re: Is this true about wayland?

#8 2024-03-09 16:01:07

Re: Is this true about wayland?

#9 2024-03-13 00:20:09

Re: Is this true about wayland?

#10 2024-04-27 06:02:41

Re: Is this true about wayland?

#11 2024-04-27 07:46:17

Re: Is this true about wayland?

#12 2024-04-27 12:36:31

Re: Is this true about wayland?

#13 2024-06-14 09:02:47

Re: Is this true about wayland?

#14 2024-06-14 12:12:49

Re: Is this true about wayland?

Board footer