Remaking X11

Back in March 2023, I started working on my window manager for the X window system. I had a clear idea of how I wanted it to be; hackable like AwesomeWM but with a friendlier API, and also does compositing to draw widgets, instead of the traditional way of spawning X windows to act as drawing layers.

Window managers in X are implemented as a program being the middleman between the X server and its clients. WMs can intercept certain requests from the clients and act accordingly but with a limited control over the server which may do or refuse to do what you want.

My WM was a bit too ambitious, as I needed custom input handling, something not exposed to X WMs, or so I thought until recently XEvIE extension was brought to my attention while I was measuring the scope of what needs to be implemented to be worth calling an X server, however as stated in the wiki, it was a buggy extension and not really used anymore. Someone might just suggest to write a wayland compositor, and they would be right, except I am using a legacy Nvidia GPU from 2008 with Nouveau driver, I could not use Wayland. All right, lets remake X11 !

By June 2024, the X project will be 40 years old, and X11 is 36 years old ! Okay, to be fair, the X project didn’t have a consistent versioning scheme. X11 we know today is actually X11R7.7 released in 2012, the ever last change to the nicely presented X protocol followed by bug fixes, patches and XWayland.

So, what could X11 do better ? Move the compositing and window management responsibilities to the server itself. Most if not all of the historical and technical reasons behind not having server side compositing and window management do not apply today anymore. I am also taking into consideration X12 ideas or at least what could be done without modifying the underlying X protocol specification, too late to change it, not like it is within my ability to decide that.

Before defining the scope of the remake, I would like to quote a remark from Wayland’s FAQ:

The problem with X is that… it’s X. When you’re an X server there’s a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this.

I have to agree to that statement, although I will still look ignorant considering that I am taking the challenge of remaking the X window system alone, I can never do everything. So here is what has to be implemented on top of the base protocol to ensure that most modern X11 applications will work:

• xkb
• xi2
• randr
• dri2 + glx

Extensions required by compositors (the server will do their job anyway), and recording software like OBS Studio:

• composite
• damage
• xshm

You really do not need a screen saver, not going to implement this:

• screen saver

Other extensions that might get implemented depending on their complexity and usage across existing applications:

• record
• big requests
• xc misc
• dpms

This is just a few of all the extensions that exist. I didn’t bother mentioning likely no longer used ones.

For those interested in what concepts and frameworks are needed to build this project, you will have to interface with:

• DRM (Direct Rendering Manager) for managing the displays video outputs.
• GBM (Generic Buffer Manager) to allocate GPU memory, which also will prove to be a problem with Nvidia cards running the proprietary driver with no GBM support (there are many of them).
• A graphic API. I went with EGL + OpenGL since Vulkan is too alien to my GPU.
• UNIX Sockets, that’s what the X server uses for IPC.

Now the controversial part, I picked Hare programming language due to its comparable simplicity to C, on top of providing the tools to write safer code. The premise of conserving Hare’s design for years to come is perfect for this project. If I ever manage to release something, I would like to forget about it once it becomes irrelevant to me, someone in the future will still be able to pickup where I left off, or build the source code with little to no hassle. Well, that’s true for when Hare 1.0 is out, one can only dream.

My progress is very slow, mostly spent trying to understand how X does things. I really want to have a prototype to at least show something.