I'm really keen to hear from someone who knows a bunch about X and WL to hear why there's such a huge difference in line count here. Is this analogous to OpenGL vs Vulkan where WL is a much lighter layer than X is?
Yeah Wayland takes like 90% of the features of X and goes "you're on your own, window managers / desktop environments!" and if you complain they just say that's out of spec, working as intended, wontfix.
It's like the exact opposite of what the Linux desktop needed.
X is a protocol just like Wayland. One of those protocols contains a standardized interface to implement window managers the other doesn't. The argument people are trying to make is that a display stack should have such a standardized interface.
It’s always quite ironic to me that the same people that want to burn SystemD at the stake for ‘trying to do everything, Linux programs should be small and modular’ also lambast Wayland for ‘not just implementing everything and the kitchen sink, like good old X used to do’.
It is just your personal assumption that they are the "same people". But it would make sense because due to lack of standardized interfaces Wayland forces every functionality into a monolithic implementation which is the opposite of small and modular.
X does not implement everything and the kitchen sink. A bare Xserver won't even be usable without a dedicated window manager, the compositor is completely replaceable and runs as a separate process, etc. Just because it is perceived by some to be bloated doesn't mean it is monolithic.
What Wayland really is a way for multiple applications to get access to and share dri/drm and evdev (kernel interfaces for putting stuff on screen and getting input respectively), nothing less and not much more. To enable that Wayland defines an IPC channel which is designed for extensibility, and there are some defined extensions to cover more desktop-like usecases (clipboards and whatnot). Some extensions are more widely supported by different compositors than others.
For links, this docs page listing many (all?) wl extensions kinda gives you an idea what wayland core does not handle, and also what in general is available through wayland: https://wayland.app/protocols/
Found that pretty quickly and it doesn't go down a point-by-point feature comparison but gives you some idea of what's up in the "introduction" where it notes that Wayland doesn't include things like keymapping functionality, so that's all up to each compositor to implement. Excerpt:
> From a user's point of view, Wayland is nothing more than a framework. In particular, Wayland itself does not implement any display server that should correspond to the Xorg server. In Wayland, compositors are display servers, implemented by various projects. A compositor also serves as X's window manager (and X's compositor).
> This means users first have to choose a compositor, and via that compositor they "configure the server", i.e. set screen resolutions, input and video drivers options, etc.
> [...]
> Some lack of specification results in chaos more or less. For example one common complaint as of 2021 is that key remapping is absent in the Wayland protocol - in Wayland there is nothing that corresponds to xmodmap of X. Each compositor offers, if any, their own way to remap keys.
> The situation however is not totally random - many compositors depend on the library "wlroots", which abstracts such common tasks, and is aimed to be impartial. First started as a subproject of the compositor Sway, it now is used by many compositors. Exceptions include mutter and KWin, i.e. GNOME and KDE, and Weston.
TL;DR minor WM/DE projects have circled around wlroots as a life-raft to fill in the missing functionality, while major ones have gone their own way, resulting in extremely basic functionality potentially being wildly different (and having a different set of bugs and quirks and how-to-configure-and-use-it) depending on which compositor you're running, or even simply being absent on some.
[EDIT]
Unsurprisingly, Gentoo's cousin distro (if you will), Arch, has an even better page on it:
Note especially the part where it's possible for a given compositor not to work with certain graphics hardware, while others will. That's how little help Wayland gives to desktop environments and window managers. To get the equivalent of Xorg you'd have to get everyone to agree on a single fairly-big and featureful compositor and only use that.
Or, good lord, look at the display manager support table. LOL.
With x you're just bringing a window manager that plugs into the x-server. With wayland there's no standard 'window manager' plugin to arbitrary wayland servers. So the wayland example is doing more things (lots is handled by wlroots though).
Also not discussed - the wayland version implements a lot more features, comments, and boilerplate. The one in OP is 178 lines with comments and features basic window control.
It would be really interesting to see a Wayland version with equivalent functionally to the X one to get some idea of what the real difference is in complexity.
