Xpra: Persistent Remote Applications for X11

First off, backwards compatibility wasn't actually broken. X11 apps work fine under Xwayland. All the weird bikeshedding that happens in Wayland isn't as important because we have working compatibility bridges and all the old stuff still works.

Second, "don't break userspace" is specifically a Linux kernel policy. The only other organization in FOSS that has such a slavish devotion to backwards compatibility is WINE[0]. Desktop environments are perfectly fine with, at the very least, breaking ABIs, because you can just recompile the ocean. I suspect this is the Free Software equivalent of "firing shots to keep the rent down" - i.e. making the software neighborhood undesirable for proprietary software vendors who will have to deal with these annoying and arguably pointless transitions every couple of years.

The reason why we needed to get off X11 is very simple: X11 is an extremely poor fit for modern hardware. The protocol supports simple drawing commands and image display, that's about it. Modern user interfaces want applications that draw onto GPU layers, composite them, and then present a final image to a compositor to be displayed to the screen. You almost can build that on X11 (modulo some frame tearing), but it's a pain in the ass and requires adopting a lot of extra protocols plus XGL which breaks network transparency[1].

The motto of X11 is "mechanism, not policy". The way this is accomplished is by presenting the entire desktop as a tree structure of windows that any client can mutate. Any widget toolkit can then build the experience it wants on top of that tree structure. The problem is that this also makes writing keyloggers and RATs trivial. X11 doesn't sandbox applications, so even if you lock down a process every other way, they can still do horrible things to other X clients and Xorg won't stop them.

Wayland fixes this by tightly restricting what clients are allowed to do to the desktop. Applications get to present their own windows, sure, but they can't touch other windows unless a specific extension is provided for their use case and the compositor allows the application to use it. In other words, Wayland is "policy, not mechanism". The downside is that now we have to codify all the slightly-different ways each widget toolkit, window manager, and desktop environment has done things under X11. This has resulted in an explosion of extensions, many of which overlap because they were made by different DEs. Wayland can of course create standardized versions of these extensions, but each standardization is an opportunity for bikeshedding.

This leads into my favorite way to tell if an application is Wayland or X11: launch Xeyes. If the eyes track your mouse over the application's windows, it's X11. Wayland doesn't have a protocol for mouse tracking, so Xwayland can't report where the mouse cursor is, unless it's on top of a Wayland window that it's already getting events for - namely, the app you're wondering about.

Ok, I suppose that is a backwards compatibility break.

[0] This also means the most stable UI toolkit on Linux is actually USER.dll.

[1] In fact, I suspect this is why Wayland was so willing to casually toss that out. GPUs and network transparency are allergic to one another.

In principle, it is an extensible generic remote buffer management framework. As such, it could be extended indefinitely without every breaking backwards and forwards compatibility and is also a good fit for modern hardware that essentially deals with remote buffers on the GPU. As someone doing HPC programming on GPU, network transparency and GPU are definitely not at all allergic.