Re: [dev] Wayland compositors

From: Hadrien Lacour <hadrien.lacour_AT_posteo.net>
Date: Wed, 8 Sep 2021 20:34:20 +0000

On Wed, Sep 08, 2021 at 08:35:33PM +0200, Laslo Hunhold wrote:
> On Tue, 31 Aug 2021 14:28:29 +0100
> Nick <suckless-dev_AT_njw.me.uk> wrote:
>
> Dear Nick,
>
> > Any thoughts, experiences, recommendations?
>
> the discussion has been very fruitful. Let me share my thoughts.
>
> Wayland the protocol is actually rather simple. It's a very thin
> messaging layer between a compositor and clients, nothing more.
> But this is exactly the problem: It's too thin and the
> Wayland-developers didn't dare to go beyond a minimal set of things.
>
This, it would have been a great goal to modularize X11 and keep the worthy
parts, not just reduce it to an exercise in "minimalism" (and complete lack of
portability) and expect the free FOSS market to magically solve the remainder.

> All of the things that are breaking are those based on
> (compositor-specific) Wayland-extensions which add functionality you'd
> expect (gamma control, screen sharing, etc. etc.). I will never forgive
> the Wayland-developers for their lack of courage.
>
> We're talking about the next generation of display/window managers, and
> they messed it up so badly! Just a few things that come to mind:
>
> - network transparency is a _good_ thing and was thrown away way too
> easily. I like being able to run GUI-applications from time to
> time via ssh. Most of the time they are just basic
> GUI-framework-programs you could "stream" very efficiently, but if
> you're talking about composited surfaces, I would expect Wayland
> to do that for me too, via a compressed stream or something.
> It's trivial to stream Ful-HD-Video P2P using modern compression
> algorithms, why wasn't this taken into consideration?
> People are always talking about moving away from the single
> computer and into the "orbit" (see Urbit, etc.). Today's
> technology makes it possible to be much more flexible in this
> regard.
> - color management was totally ignored. This could've been a strong
> point for Wayland, but instead they made it even worse than in X,
> which is actually a difficult feat. We need to move away from the
> sRGB-monoculture, especially because it's not bloaty to actually
> support proper colour management and it has tangible benefits.
> - everything about Wayland is hacky and deeply integrated into
> Linux, but what for? To get "perfect frames", as it is often said?
> This could've been done so much better, for example by going
> vector-first. Most stuff in a GUI can easily be represented by
> vector-data, which is very sparse. You do have bitmap-surfaces
> from time to time (video player, browser, games, etc.), but it
> would've been a very interesting and radical approach. The
> advantage of this is that you don't need to think about dpi and
> other shit except in those bitmap surfaces. All the rasterization
> would be the last step and not intrinsic to the protocol itself,
> but just the compositor.
>
> Anyway, to sum it up: Probably nobody here is really a fan of X, but
> it's what we have. Wayland is an underwhelming mess and they really
> dropped the ball here. The mix of (often incompatible and competing)
> extensions that are made up and forced upon us (while leading to more
> and more userspace-applications relying on them and unexpectedly
> breaking in vanilla Wayland-compositors that don't want to be tainted
> with the garden-variety of extensions) is just horrible.
>
> I used to have enthusiasm about Wayland, but now this feeling has
> completely been replaced with pity. They really dropped the ball on
> this one and I will not waste any more time with it.
>
> With best regards
>
> Laslo
>
A good rant. Let me add my biggest problem: global keyboard grabbing isn't
possible unless done by the compositor, so something like bspwm+sxhkd doesn't
look possible right now.
Received on Wed Sep 08 2021 - 22:34:20 CEST