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.
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.
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.
Right now there’s a bunch of competing compositors with different use-cases but nothing says it has to be true forever.
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.
Which compositor do you use?
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/
Seems to be a bit of a dealbreaker for people who want to use 100 percent of their screen instead of only 75 percent.
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).