Xorg is about to released.
And it's a release without Xwayland.
And... wait, what?
Let's unwind this a bit, and ideally you should come away with a better
understanding of Xorg vs Xwayland, and possibly even Wayland itself.
Heads up: if you are familiar with X, the below is simplified to the point
it hurts. Sorry about that, but as an X developer you're probably good at coping with pain.
Let's go back to the 1980s, when fashion was weird and there were still
reasons to be optimistic about the future. Because this is a thought
exercise, we go back with full hindsight 20/20 vision and, ideally, the
winning Lotto numbers in case we have some time for some self-indulgence.
If we were to implement an X server from scratch, we'd come away with a set of
components. libxprotocol that handles the actual protocol wire format parsing
and provides a C api to access that (quite like libxcb, actually). That one
will just be the protocol-to-code conversion layer.
We'd have a libxserver component which handles all the state management required
for an X server to actually behave like an X server (nothing in the X protocol
require an X server to display anything). That library has a few entry
points for abstract input events (pointer and keyboard, because this is the
80s after all) and a few exit points for rendered output.
libxserver uses libxprotocol but that's an implementation detail, we can
ignore the protocol for the rest of the post.
Let's create a github organisation and host those two libraries. We now have:
http://github.com/x/libxserver and http://github.com/x/libxprotocol [1].
Now, to actually implement a working functional X server, our new project
would link against libxserver hook into this library's API points. For input,
you'd use libinput and pass those events through, for output you'd use the
modesetting driver that knows how to scream at the hardware until something
finally shows up. This is somewhere between outrageously simplified and
unacceptably wrong but it'll do for this post.
Your X server has to handle a lot of the hardware-specifics but other than
that it's a wrapper around libxserver which does the work of ... well, being
an X server.
Our stack looks like this:
+------------------------+
| xserver [libxserver]|--------[ X client ]
| |
|[libinput] [modesetting]|
+------------------------+
| kernel |
+------------------------+
Hooray, we have re-implemented Xorg. Or rather, XFree86 because we're 20 years
from all the pent-up frustratrion that caused the Xorg fork. Let's host this project
on
http://github.com/x/xorg
Now, let's say instead of physical display devices, we want to render into an
framebuffer, and we have no input devices.
+------------------------+
| xserver [libxserver]|--------[ X client ]
| |
| [write()] |
+------------------------+
| some buffer |
+------------------------+
This is basically Xvfb or, if you are writing out PostScript, Xprint. Let's
host those on github too, we're accumulating quite a set of projects here.
Now, let's say those buffers are allocated elsewhere and we're just rendering
to them. And those buffer are passed to us via an IPC protocol, like...
Wayland!
+------------------------+
| xserver [libxserver]|--------[ X client ]
| |
|input events [render]|
+------------------------+
| |
+------------------------+
| Wayland compositor |
+------------------------+
And voila, we have Xwayland. If you swap out the protocol you can have
Xquartz (X on Macos) or Xwin (X on Windows) or Xnext/Xephyr (X on X) or Xvnc
(X over VNC). The principle is always the same.
Fun fact: the Wayland compositor doesn't need to run on the hardware, you can
play display server matryoshka until you run out of turtles.
In our glorious revisioned past all these are distinct projects, re-using
libxserver and some external libraries where needed. Depending on the projects
things may be very simple or get very complex, it depends on how we render
things.
But in the end, we have several independent projects all providing us with an
X server process - the specific X bits are done in libxserver though. We can
release Xwayland without having to release Xorg or Xvfb.
libxserver won't need a lot of releases, the behaviour is largely specified
by the protocol requirements and once you're done implementing it, it'll be
quite a slow-moving project.
Ok, now, fast forward to 2021, lose some hindsight, hope, and attitude
and - oh, we have exactly the above structure. Except that it's not spread
across multiple independent repos on github, it's all sitting in the same git
directory: our Xorg, Xwayland, Xvfb, etc. are all sitting in hw/$name, and
libxserver is basically the rest of the repo.
A traditional X server release was a tag in that git directory. An
XWayland-only release is basically an rm -rf hw/*-but-not-xwayland followed by a tag, an Xorg-only
release is basically an rm -rf hw/*-but-not-xfree86 [2].
In theory, we could've moved all these out into separate projects a while ago
but the benefits are small and no-one has the time for that anyway.
So there you have it - you can have Xorg-only or XWayland-only releases
without the world coming to an end.
Now, for the "Xorg is dead" claims - it's very likely that the current
release will be the last Xorg release. [3] There is little interest in an X server
that runs on hardware, or rather: there's little interest in the effort
required to push out releases. Povilas did a great job in getting this one out
but again, it's likely this is the last release. [4]
Xwayland - very different, it'll hang around for a long time because it's
"just" a protocol translation layer. And of course the interest is there, so
we have volunteers to do the releases.
So basically: expecting Xwayland releases, be surprised (but not confused) by
Xorg releases.
[1] Github of course doesn't exist yet because we're in the 80s. Time-travelling is complicated.
[2] Historical directory name, just accept it.
[3] Just like the previous release...
[4] At least until the next volunteer steps ups. Turns out the problem "no-one
wants to work on this" is easily fixed by "me! me! I want to work on this".
A concept that is apparently quite hard to understand in the peanut gallery.