But never as a drop-in replacement.
Yes, Wayland is supposed to replace X as the display protocol, as that is what developers have been focusing on doing in the past couple of years as we move away from X. This does not however mean that Wayland was designed as a drop-in replacement. That would be more akin to something like Pipewire-Pulse, which is a drop-in replacement for Pulseaudio, just to give an example.
I don't think there would've been a way to keep 1:1 compatibility with X whilst also following Wayland design goals.
I was trying to go off of various things I've seen online, e.g the "Wayland breaks everything" post. The "evildoer" thing is not intended to come from your point. Sorry if that was not clear enough from my wording.
counter-question, did the X Windowing System have all of these extensions within the first 15 years? Barely. Infact, the RandR extension was not finished 14 years after X, as the historic paper going over RandR 0.91 mentions that, at the time of writing, the X Extension Framework had "served them well for the past 14 years".
https://static.usenix.org/publications/library/proceedings/usenix01/freenix01/gettys.html
Going off of the "last changed" date at the bottom, this was roughly in 2002, roughly 14 years after the X Windowing System was first envisioned
After some more digging, RandR 1.0 was apparently finished in 2002, on the 4th of October. You can see this when checking this commit and which lines it has removed.
This is an extension to X, with the equivalent on Wayland being literally the wlrandr extension. That was talked about in 2013 by Phoronix.
Some of the most common things that are complained about often have been fixed by the Wayland Contributors 11 years ago from now.[1]
Two things:
- GNOME Shell has had it's own Screen Casting interface, it only uses XSHM and XComposite directly as a fallback. This is evidenced by things like:
- Again, PipeWire.
Recording a traditional X11 desktop is easy with existing tools. Because every application can grab the window content of any window or monitor on the X11 server, screen sharing is rather simple to do. Many applications support this method like ffmpeg with the x11grab source or apps built with the Electron framework. The typical APIs for this are XShm and XComposite, which are only available on X11.
With wayland, this becomes more difficult from a developers point of view. The security architecture of wayland forbids unauthorized access to other windows. No capture API is provided by wayland itself.
Instead, applications must explicitly request the user to grant them access to a screen or window. This is done through xdg-desktop-portal, a D-Bus API that was originally invented for sandboxed Flatpak apps.
The actual window content is delivered through PipeWire in the form of a video stream. To access it, an application has to connect to this stream and negotiate a format with the stream source.
- Dafabhoid on Github
Before you say it, yes I know that says "No capture API is provided by wayland itself.", but does that matter to the end user if they can just select "Window Capture (Pipewire)" in OBS and call it a day?
How can something that did not exist to begin with break?
Do Windows Programs break on Linux because they aren't written to work on Linux?
What about macOS binaries? FreeBSD?
Are all of these inherent and often intended incompatibilities considered breakage?
No. The compositor is the desktop component that implements the Wayland Protocol and puts all of your Wayland clients into one usable output.
That makes sense given:
The compositor is in charge of combining the contents of multiple surfaces into one displayable output.
- Wayland protocol | Wayland Explorer
that being the lack of an xrandr alternative, although wlrandr exists ↩︎
The name is in all caps.)
