And people wonder why Linux lags behind Windows and macOS in terms of desktop smoothness and quality.
When all is said and done, you may as well remove the legacy cruft (drawing and filling primitives, the fucking X font architecture, etc.), delegate remote display to a protocol that is better designed to support it such as RDP or PipeWire that only gets loaded when necessary (which it's not for 90% of users in 90% of use cases), and streamline the display server itself to just that which modern clients actually need, and that's Wayland. Wayland just brings Linux, barely, up to the state of the art set by Windows, macOS, iOS, and Android -- which have prioritized perfect frames and smooth compositing and presentation since forever ago.
What I like about X, that is missing in Wayland, is that you no longer can run the X server on a machine and connect to clients (application) on another.
And if you think about it... this day with the cloud it could have been the killer feature! Nowadays is normal to have programs that run in VM in the cloud with a sort of remote desktop client. X11 would have been more performant even with not so fast network connection, because you have the rendering done in your local PC and only commands that pass on the network.
And if you think about it for a moment, isn't how web browsers work? Where you have the server that sends some HTML to the browser (nowadays JS and other stuff) and the browser doing the job of rendering? If you compare the X server to a web browser and the X client to a web site, isn't very similar? And this is the model that is winning nowadays.
Meanwhile we think about a new graphical server that cannot be used on a network, in a period where we are returning in the era of mainframes, when X was created (granted, nowadays is not a big PC in a room but a multitude of VM in the cloud).
The problem is not X, the problem is that X was never used at is full potential because we are so used to the (to me not optimal) model that Microsoft/Apple proposed to us.
You could have had monitors with an integrated X server, like in the past you had serial terminals, without fans, cables, and stuff on your desk, just a small ARM processor with a GPU to render things on screen. And a single network cable going to a computer that you had anywhere else in the house/company, or in the cloud.
No need for HDMI or other display interfaces, just run a network cable to each monitor, plug keyboard and mouse on the monitor, you are done. The GPU is in the monitor, doesn't it make more sense? How much money that could have saved to a company? It would have been more efficient than thin clients that connect to an RDP Windows machine that has to have a GPU just to render the remote session? Large installations like displays used for public information? Why use a full screen web browser, it's overkill, when you could have simply launched a X server on the particular display, then launched an application on a server and connected to the IP of that particular monitor to display everything you wanted?
The architecture of X was modern 40 years ago when it was invented. It in some ways predicted the future, and now that we are discarding it for something that tries to imitate Windows/macOS (badly, because these operating systems just works well, Wayland doesn't). Is it worthed?
Web browsers (and Electron) are replacements for NeWS, not X really. That's part of the reason why Electron won't go away, the architecture advantages are too great: have the server push running code to the local display to take advantage of local acceleration. NeWS was awesome in its day, and it kind of lives on in the form of browsers and Electron.
I don't really see the point of Wayland, to me X was just fine, sure, maybe it was time for X12, but was a completely new display server needed?
Only just barely. And they told us it could stop at any time. All the developer energy and support is behind Wayland, so that's what you should be using.
> I don't really see the point of Wayland, to me X was just fine, sure, maybe it was time for X12, but was a completely new display server needed?
The developers closest to the graphics stack say yes, so I defer to their expertise.
Really, this has been discussed to death many, many times. The arguments for X (or an X-like architecture) invariably come from people who are ignorant of the actual issues involved. Here's a video by Daniel Stone that addresses the main points; note that it was made 8 years ago and people are still arguing the points: https://youtu.be/RIctzAQOe44
As far as the graphics stack maintainers are concerned the debate is pretty much over, and Wayland won. X will get little to no developer attention going forward. Unless you want to take responsibility for the X server, your choices are to get with the program and get on Wayland, or find your use case completely unsupported.
(Note that when it comes to large projects like Xorg, corporate sponsorship is critical. The corporations are putting their money behind Wayland, not X.)
My impression is that latencies kill X performance. Having a server under my desk is one thing, but running even something like xedit halfway across a world is painful. It may be possible to update these tools to be less synchronous, but I’m not sure this is a great use case, certainly not for new applications.
> No need for HDMI or other display interfaces, just run a network cable to each monitor, plug keyboard and mouse on the monitor, you are done.
This would be great. Every monitor has at least a frame buffer and there is no need to push every pixel to the monitor 60 times a second. Worst case scenario is you have a sporting event where you need to push every pixel to the screen 60 or more times per second, but, most of the time, there’s no such need.
I'd love to see a new design with network transparency in the current internet age on the foreground.
I remember working in a room with 20 big-screened X terminals connected to one server over one shared 10 Mbit 10Base-T. And it worked amazingly well.
This was when Windows was in its infancy. I'd love to see that kind of vision again.
Nowadays with modern video compressing protocols also sending the video like RDP doesn't require a lot of bandwidth either and has an acceptable latency to be fair, but with X it would be even better (and it is, if you ever used X over ssh it works great)
This is true of RDP also. The initial versions of RDP were basically GDI over the wire. Of course it's been expanded since then to include DirectX calls, etc.
> The load on the network is lower.
That is incorrect. RDP is actually usable over an internet link; X11 is far too chatty and ridden with roundtrip latency for that use case. Even VNC does better over the wire than X.
> That is incorrect. RDP is actually usable over an internet link; X11 is far too chatty and ridden with roundtrip latency for that use case. Even VNC does better over the wire than X.
Yes I use it over an internet link and it works reliably.
But the main difference between RDP and X11 forwarding is that RDP forwards the entire session, while with X11 you forward the single application. With X11 forwarding you can indeed run on the same X server different X clients. That can be an advantage in an era of microservices, because you can see an X client as a microservice, and thus have a workstation (a X server) run a plentful of X clients each one on a different machine/VM/container.
That's not even true. The DRI3 X11 extension uses the exact same buffer swap mechanism like most Wayland compositors. Running locally you get the best of both worlds with X11 already.
> So, your X server is really effectively nothing more than a shitty Wayland compositor.
Couple of things: 1) you use DRI3, you lose network transparency. KDE apps run like a pig stuck in shit over network links because Qt on X was built to take advantage of the massive speed of DRI3.
2) Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. Wayland fixes this by making the display server, window manager, and compositor all one process.
Wayland solves problems you do have, you just don't know you have them.
No it is a much better Wayland compositor because unlike Xwayland it provides full backwards compatibility. You even need much less boiler plate code to get a file descriptor on X11 as compared to Wayland.
> Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path.
This is only makes a difference for rare events like moving/resizing windows. For static window positions it is the exact same path as Wayland. In practice Wayland had historically even much worse latency than X11. This has only been fixed a few years ago. Latency has low priority for Wayland developers. And as such Wayland does not beat uncomposited X11 in latency to this day.
"This is only makes a difference for rare events like moving/resizing windows."
This is actually wrong, that type of split affects the rendering of every single frame. Also, uncomposited X11 is a bad idea for a number of other reasons, the only reasonable comparison to make there is composited X versus Wayland, which is what all the benchmarks I've seen are aiming for.
That also mean that you have a single process that if it crashes you loose your entire desktop session crashes. In the old X days I used to have my compositor crash a lot of times (good old days of Compiz with a ton of effects), but everything else was still functional, and I could simply restart it without loosing my entire desktop session. Or you changed the settings on GNOME, in the past just restart the WM, with Wayland of course you have to log out and login again.
Also, things that on X were simple (for example having an application that captures the screen) are difficult in Wayland, and the only way to do so is to incorporate that functionality into the window manager itself, that becomes a monolith very quickly.
Speaking about latency, to me is stupid. Like I said, in the old days of Debian 6, with a core2 and integrated graphics I used to run GNOME 2 with Compiz, I had smooth graphical effects and it did run fine, with a memory usage less than 100Mb in idle.
Nowadays we have hardware that is orders of magnitude faster and we have more problems that back in the days we didn't.
You actually can do this with Waypipe. Also, I'll mention this again: most Wayland implementations include the X server (as XWayland) and support this as a backwards compatibility option.
"If you compare the X server to a web browser and the X client to a web site, isn't very similar? And this is the model that is winning nowadays. ... Why use a full screen web browser, it's overkill, when you could have simply launched a X server on the particular display, then launched an application on a server and connected to the IP of that particular monitor to display everything you wanted?"
It's really not overkill though, people build web apps because the stack actually works well. Developers seem to really want to use those browser features. X on the other hand is very old and hasn't kept pace. The most obvious example I can think of is OpenGL: indirect GLX doesn't really work any more and hasn't for quite some time. It can't really be updated either without complicating everything, because any performant use is going to require loading code into the server. If you want remote GPU rendering, the best way to achieve that currently is to use WebGL and WASM (and later WebGPU when that's ready).
"we are discarding it for something that tries to imitate Windows/macOS (badly, because these operating systems just works well, Wayland doesn't). Is it worthed?"
Well, worst case scenario, Wayland is just a minimal way to get your browser window on the screen. I think this is another big misconception that people have. Wayland generally sits at a lower level in the stack than network applications, and it really has to be this way if you want to support hardware accelerated clients. Wayland is made for the case where you've already decided you have a GPU buffer and you want to put that on the screen. You could build something else on top of it that runs over the network (and this is what web browsers do, it's how XWayland works, it's how your VNC/RDP client works, etc) but somewhere in the pipeline those will need to have that fast local path where they render to a GPU buffer. And that's where Wayland comes in. It's not that the developers are trying to copy Windows/MacOS, it's that you have to do this if you want to get a good experience out of a modern GPU.
Or because there is not an alternative. Building graphical software is difficult because you have to interact with graphics. But, what if we have a protocol where you simply open a network socket and write some messages on it that says "write this text hear", "draw a line from X to Y"? Well, that is how X clients work.
> Wayland generally sits at a lower level in the stack than network applications
That to me is not a good thing. One of the main advantages of Linux/UNIX systems in the past was that X was a userspace application, and if X crashed the entire computer didn't crash, like Windows does, you restart the X server and you don't loose your work. Of course modern desktop environment crash with X, and that is a bad thing (but an X client can, and should, if the X server crash, just try to reconnect with the new X instance and redraw its window, like you reconnect to any other socket, or worse case scenario the program continue to run just without the GUI!)
I mean, that is also how the Web Canvas API works. If you want to control this with some messages on a TCP-ish socket then you can use websockets. The web browser already appears to be a superset of all the networked functionality of X.
"One of the main advantages of Linux/UNIX systems in the past was that X was a userspace application"
Wayland still is a userspace application too. The protocol itself is what is at a lower level of userspace than X was, of course the compositor can also implement high level features as it sees fit.
Yes, in a very inefficient way, you end up using 1Gb of RAM to do something that could have been done with 1Mb. Not important for desktops, but for embedded applications?
> Wayland still is a userspace application too. The protocol itself is what is at a lower level of userspace than X was, of course the compositor can also implement high level features as it sees fit.
Wayland is based on KMS that indeed is a graphic implementation in the kernel itself.
Modern Xorg is also using the KMS API. If you don't want any fancy features and just want to draw some lines then you probably want to skip Xorg and Wayland altogether and use KMS directly.
Could you explain why these concepts are so flawed, for those of us to whom it is not immediately obvious?
Additionally a Desktop system in general is much more than a bunch of bitmaps blittet together. Applications need to interact and such functionality has to be tightly integrated into the compositor with standardized protocols otherwise it will be impossible to have such functionality. Taking screenshots, drawing to the root window or knowing about coordinates of windows from other programs are some examples.
Oh and what gives, wayland just has an extension for this use case!
HDR is work in progress, there is nothing unchangeable in Wayland that would disallow different buffer types.