undefined | Better HN

0 pointsjude-5y ago0 comments

Don't get me wrong, I'm not trying to suggest that the X devs are ignorant of this. I too have both deep respect and gratitude for the work they have done and continue to do.

I'm only frustrated that I can't get a straight answer as to what problems Wayland is solving that can't be solved with less difficulty and breakage by repairing X11. I'm sure the X.org developers have an answer, and I would love to know it, but I'm not getting it here in this comment tree.

0 comments

3 comments · 1 top-level

kaba05y ago· 2 in thread

Here you are: https://youtu.be/cQoQE_HDG8g It’s a great presentation by one of the guys behind wayland, who worked on X a lot before.

Basically, X has a fundamentally misaligned abstraction of the underlying hardware - which is expected based on its age. When used with a compositor, it is basically a middle-man with no function whatsoever. So Wayland decided to cut out the middle man and pass events directly between client and compositor. But please watch the video, I think it will answer all your questions.

Also, it’s not like X will be totally deprecated, XWayland is an API implementation of it that will be supported forever.

jude-OP5y ago

Right, and as I said elsewhere, this is a problem with the reference implementation being crusty, not X11. That seems to be the point the speaker is making as well.

Like, I'm fully supportive of having the X server simply manage DRI3 for a bunch of clients and composite the results. That's all well and good.

I'm less supportive of doing this while also removing all support for the other things that the X server provides the ecosystem:

* Unified input/event capturing and forwarding

* Unified screen capturing/recording

* Window management

* Clipboard

* Structured IPC (on top of which you get ICCCM and NetWM)

* Xrdb

* Xprops

* Notions of windows in general (everything's now client-side)

* Fonts

* Drawing APIs

These were all standardized things that users could count on always being available, regardless of which GUI programs they used. Wayland completely punts on these things and defers them to extensions.

Before you ask, I've already seen the "Wayland is a protocol; these are all extensions" song and dance routine. That's a cop-out. Dropping these things means that there will now be multiple incompatible implementations of the same concept, and no way to mix-and-match them because they now all have to be built into the same process that does your window management. Wayland implementations completely destroy this digital commons, for no apparent reason or gain for the users. The only people I see potentially benefiting from this are full-fledged DEs who can leverage their compositors' incompatible implementations to enact a form of lock-in (i.e. your GNOME programs are no longer guaranteed to run in KDE, and vice versa). So, why do this?

kaba05y ago

> Unified input/event capturing and forwarding

This is simply insecure. “It is easier to cut holes into a solid block than to patch something that looks like swiss cheese”. What reason does a random app has to see each keypress, when it doesn’t have focus? Do you trust eg. the teams app or the million other app to be a good citizen?

Screen capture is implemented with pipewire in a better way than before.

Fonts: noone uses the old font API of X, even under X. And third party libs like cairo work on both wayland and x, so nothing is lost here.

Drawing APIs: show me any app that uses it and was upgraded in the last two decades. Feel free to use a CPU only drawing API, I prefer not watching the line getting rendered.

Also, as I already mentioned XWayland is important for exactly this reason - it is a completely backward compatible X implementation, on top of a better display protocol. What’s the actual problem, because I still don’t see it.

There is no need to have incompatible implementations of each, and just look at the three main wayland implementations: they share many of the work.

1 more reply

j / k navigate · click thread line to collapse