How X Window Managers Work, and How to Write One (2014)

But what you list is not enough, though. There are enough extra bits that goes well beyond what Wayland provides today, like ability to write a standalone wm without having to build a whole compositor, for example, that you'd end up with something quite substantially unlike Wayland if you went down that route and looked at which pieces of X11+extensions people are actually using. It'd be far less than full on legacy X11, but far more than just Wayland.

It doesn't matter if it's not X. Nobody but extreme purists would care if it's not exactly X. What will matter is if you lose capabilities.

E.g currently my preferred wm (bspwm) doesn't have a Wayland alternative, so a Wayland compositor isn't a viable option for me without changing my workflow. Sway might be nice, but it's different and I have no compelling reason to put in the effort to make a switch until running Xorg starts becoming problematic. One day, maybe I'll feel compelled to switch but it won't be soon.

Even so, Xorg will hang around for decades in the form of XWayland because of old X apps people still use (e.g. none of the terminals I have installed on my system except for gnome-terminal supports Wayland).

>Still not going to amputate my leg over a stubbed toe even if RMS considers the toe cancer.

I didn't say you should. I worded what I wrote specifically to indicate that I'm not passing any judgement on whether you made the right choice or the wrong choice.

There are many people who bought nvidia GPUs because they worked fine, and were rightfully worried that they'd stop working fine if their DE of choice decided to switch to wayland or became abandoned. I empathize with their situation completely.

All I'm saying is that you made the choice to buy hardware that requires a proprietary driver, and so you have to live with the consequences of that choice. This is not something unique to this situation involving nvidia GPUs. Only you have the right to decide whether it was a good choice or a bad one.

Edit: also this one somebody wrote in HTML5 and typescript https://github.com/udevbe/greenfield

Redraw time when the systems were slow enough to for the client app to not be fast enough to render the content, sure, there's no way of avoiding that. But again that is not a protocol issue. Wayland can't help you with that. Blitting the graphics onto the screen was back to being limited by the hardware from MIT-SHM arrived ~'91.

> Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.

Upgrading the core protocol has hardly been tried. What has been done is piling on extensions - ironically exactly the same mess happening with Wayland to try to get back to reasonable parity with X. But even most of those didn't go very far. E.g. none of them tried stripping out more than a tiny subset of legacy stuff.

The very first message an X client sends includes the protocol version. Nothing stops you from starting by bumping the major protocol to 12, removing whatever you like from the protocol if a client connects and asks for 12, and upgrade Xlib to ask for 12 first and try again with 11 if the server barfs. Nothing stops you from making a version of a server that just refuses to let clients asking for 11 to connect, and defer those to requiring a proxy to translate/implement whatever you strip out if you care rather than upgrade the clients.

I understand why people got fed up and did Wayland instead, but that was largely organisational, not technical.

If there had been the will they could have done a dozen iterations of the core X protocol in the time it has taken to get Wayland reasonably usable and removed things piece by piece instead. To take a concrete example, there are about half a dozen ways of rendering text in X. Nothing would have prevented saying that X12.0 has XRender by default so you don't need to query for it, and that no other text-like rendering operation than RenderCompositeGlyphs8/16/32 is supported and just yanking all of the font code out of the server. If anyone cared, taking the old code and implementing a client side library providing the old string drawing functions would keep compatibility easily enough.

Nobody seriously tried doing this, because the politics of it was maintaining full backwards compatibility or building something new.

Wayland was a technical solution to a political problem. Frankly a fork and iterating would have likely gotten buy-in much faster.