I never got to fully understand Wayland's model, but if this means that something that previously was handled by the display server for everybody, and now every single desktop environment (or at least something like wlroots) has to solve it over and over again... how isn't this a step back?

Cutting out bloat, just like you loose weight by cutting of your head.

Wayland is like X11. Xorg implements the X11 protocol. There are other X11 server implementations — XWin32 is one example on Windows.

Nothing has changed with Wayland except we have a new thing and lots of groups writing compositors. And this is great — Mutter, Kwin, wlroots, Mir — and they will all speak a common protocol for putting stuff on the screen and handing input events. And projects with similar use-cases “desktops” are standardizing on common dbus interfaces for non-display stuff.

This is genuinely so much better than the Xorg monoculture. Wayland’s design has made it possible for lots of different groups to implement display servers and have interoperability because what we had before was “X11 actually means do what Xorg does.”

There’s lots of in-fighting about the scope of Wayland and people that want to make a protocol for putting pixels on the screen also handle “desktop stuff” like audio, screenshots, screen recording, keybindings, input automation, authentication. I think this is misguided because it would effectively turn Wayland into a generic message bus between “apps with windows” and the display server when we already have a generic message bus for every application — dbus.

Right now we have things like:

org.gnome.Shell.Screenshot | org.kde.kwin.Screenshot

org.gnome.Shell.Screencast | org.kde.kwin.Screencast

which after shaking out will be promoted to org.freedesktop.* after standardization. Despite the fact that notifications have been "DE specific" in the same way for years and years nobody seems to complain about org.freedesktop.Notifications.

I agree. On one hand I can understand the need to shrink code, focus on the core functionality etc..., but on the other hand X has e.g. "xset" and "xbindkeys" which can be used for all X-desktops (or "Window Managers" or however they're called). With wayland each single desktop environment has to re-implement all that functionality => looks like wasted effort to me - the modularity (from the point of view of functionality) of X is lost in Wayland.

One of the innovations since the 1980s when X was designed are shared libraries, so you can have libweston and wlroots now https://github.com/swaywm/wlroots

X11 used shared libraries since its beginning in the 1980s.

SunOS paper about shared libraries, 1987

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.9...

SunOS 4.0 lists "dynamic linking" as new feature, released 1988

https://en.wikipedia.org/wiki/SunOS

AT&T System V Release 3 got shared libraries in 1986

https://en.wikipedia.org/wiki/System_V_Release_4#SVR3

While the first X11 release was in 1987, the fundamental architecture was designed already since 1984, and this architecture includes a heavyweight server that implements things that in most other window systems are done client-side.

There’s nothing from someone implementing a single extensible compositor that everyone standardizes to build their DE. It’s the same as Xorg and X11.

Right now there’s a bunch of competing compositors with different use-cases but nothing says it has to be true forever.

> Wayland is a protocol.

A protocol definition could cover multi screen support, requiring implementors to do something sane. Of course one of the reasons that Wayland exists was to cut down the bloat X had accumulated over the years. Given that it is rather surprising that the Wayland spec isn't just an empty page.

> Wayland is a protocol. It has nothing to do with multi screen support. You're talking about the compositor you used. The one I use handles multi-screen setups quite well.

Which compositor do you use?

I use Wayfire [0], a customizable compositor based on wlroots, the same base as sway. It's quite involved and not absolutely perfect yet, but it has some features I haven't yet seen on other DEs like being able to swipe horizontally on your touchpad to smoothly switch workspaces (following your fingers) and the satisfaction of having it properly configured is pretty high.

There have been 3 issues I've had regarding it, 2 I'd call minor:

- I haven't found a way to rearrange external displays, though it is theoretically supported

- After a bug in my TV switching to the lowest possible resolution through switching the input in home assistant it would not work with 4K again until after a complete reboot (so it may not even be a wlroots issue)

- XWayland apps are unresponsive in the upper half of the second screen (4K at 1x scaling)

Using mostly native Wayland apps neither of these have been deal breakers for me. Something under-discussed is that virtual desktops are per-screen, which I find quite cool.

So that's my adventure with Wayfire, but I would assume that Gnome and KDE have perfected multi-screen usage on and off of Wayland by now.

[0]: https://wayfire.org/

>XWayland apps are unresponsive in the upper half of the second screen (4K at 1x scaling)

Seems to be a bit of a dealbreaker for people who want to use 100 percent of their screen instead of only 75 percent.

Wayfire's developer here, have you looked into output configuration on our wiki?

Also, is there a chance your 4K screen has negative coordinates? It is well known that Xwayland does not react if an output has negative coordinates (or at least partly negative coordinates).