About Waxed Display Server

Early 2025. My KDE Plasma desktop stopped working as a remote desktop.

At first I assumed some configuration setting had broken. Plasma does that occasionally, nothing new. I figured I'd just open up the remote desktop settings, look at whatever error might pop up, fix it, and be done. I'd been keeping updates sparse on that machine precisely to avoid breakage, so the timeline I experienced might not match when things actually changed upstream.

What I didn't realize yet was that my system had quietly switched to Wayland. Visually everything looked about the same. There were subtle hints here and there, applications not remembering their positions being the most noticeable, but nothing that screamed "you're on a completely different display protocol now." In my mind I still just had a broken remote desktop that needed fixing. But the properties panel in Plasma looked different too, almost as if remote desktop wasn't really a feature anymore.

Then it clicked. "Wait, I'm running Wayland now, not X11. Why?"

Still determined and fearless, I thought: fine, I'll just get remote desktop working in Wayland. How hard can it be?

Turns out it was very hard. Bordering on impossible. And this was by design.

Desktop portals and screen sharing were just becoming usable around this time. But actual remote desktop streaming, my specific use case, was and still is impossible because Wayland demands a user confirmation dialog before allowing any screen capture. Try doing that on a headless server where there's nobody to click "allow." This is where my appreciation for Wayland began its gradual decline. I just wanted ffmpeg to grab a KMS surface and stream it over my local network to another PC. Why is that so difficult? It really shouldn't be.

Turns out the privacy argument won in Wayland's design, making the whole capture side as complicated as possible by intent. Now you need multiple dependencies: Pipewire, desktop portals, and various other components working together. And still no simple ffmpeg path to just grab a framebuffer and go.

I let this rest for a while and begrudgingly continued using KDE Plasma, still my desktop of choice at the time. But new issues kept surfacing, things that had always been broken in Wayland but that I was only now starting to notice and get annoyed by.

Applications not opening where I closed them. A feature that has existed in desktops across all platforms for decades was somehow gone. When I dug deeper into why, I found the reason: Wayland internal politics. They had been discussing this very issue for years across hundreds of comments and multiple different protocol proposals. Somehow window positioning was now a security issue? Like, what? Why is this even a discussion? It almost seemed as if they were actively trying to make the Linux desktop a bad experience.

But fine, my appreciation for Wayland had already reached the "lead by stupidity, don't get involved" stage. I focused on desktop streaming again and decided to tackle a seemingly simple issue: the mouse position.

My setup involved a headless server with a dummy display dongle plugged into the HDMI port. This dongle would emulate whatever resolution I wanted, which let me stream at exactly the size I needed. The receiving end, my actual workstation, would run at that same resolution. This meant mouse coordinates would map 1-to-1 between the two machines. If I moved my mouse to coordinates (960, 540) on my workstation, the headless server would receive those same coordinates. Simple, clean, and perfect for my own little desktop streaming project.

But Wayland had to interfere again. Global coordinates are a big no-no in Wayland because of those same dreaded security reasons. The protocol deliberately obscures where things actually are on screen, which completely breaks my 1-to-1 mouse mapping approach.

I'm not even going into the speed, or more accurately the snail's pace, that Wayland progresses at. Want a new protocol? Enjoy a flamewar and at least two years of your time. It is a rotten community.

Something Better Had to Be Possible

We're now approaching the end of 2025. My view of Wayland had sunk to thinking of it as stupidity policies enforced by stupid people. I liked the X11 world more and didn't really see any value in Wayland anymore, besides the graphics stack being genuinely better thanks to KMS and DRM.

I wanted to run something that had the improvements that came after X11 but without the idiocy that is Wayland. Initially I thought I could create a set of Wayland protocols that would mimic X11 behavior. I quickly came up with the name "Waxed" which stood for "Wayland as X Enhanced."

But after thinking this through I realized that making these protocols would mean I'd have to build my own compositor too. That seemed like too much work and a lost project from the start. Why would anyone use my compositor that deviated completely from every other Wayland compositor? And upstreaming my protocol ideas into their political mess? No chance of that ever happening.

In my mind I still held onto the idea that a new X11 alternative couldn't really be this bad, right? It felt like Wayland was a genuine degradation in terms of features you use daily. Great that HDR now works, but annoying that your windows don't remember their positions. And any solution would be compositor-specific anyway.

How could anyone design a protocol that bad and still think it's a good idea? It should be abundantly clear that their structure promotes fragmentation and ensures only the desktops with the most developer power survive. Wayland over time will simply accumulate so many protocols that it becomes near impossible for any hobby developer to build something on their own. It would just be too much work.

Surely something better must be possible. Anything?

AI to the Rescue

We're now at the end of 2025 and I hadn't used any AI coding tools yet. I had seen them around and had used plenty of AI chat sites for code projects, but always in the sense of "copy code into chat, ask a question, copy answer back out." It's a flexible way of using AI but a very slow one too. It works fine for writing a script or single-file projects.

Here I started playing with the well-known command line coding tools. I used Claude Code but with the GLM 4.6 model on some other local project just to see what all the fuss was about with these CLI tools.

I was impressed. It actually worked really well, mightily impressive even. As a senior C++ developer by now, this form of AI usage felt like having a superpower. You can steer the model enough, just based on your own knowledge, that you can actually get useful results out of it. Results a non-developer would never be able to achieve even with the same tools.

This made me excited about AI and gave me the thought: hey, let's design a display server that is just far better than Wayland and does things differently. I wasn't actually expecting AI to be able to do this, but I tried it anyway.

First with a simple KMS and DRM setup to show an RGB gradient on screen. Then to show it on both my monitors. Then to play with resolutions and learn new tools in the process like drm_info. Everything was eventually actually beginning to work.

So I upped the game and added Vulkan. Surely it wouldn't be able to handle that too?

I chose Vulkan after briefly considering OpenGL and software rendering, but quickly settled on Vulkan. Why GPU rendering at all? We're in 2026. Even low-end hardware has a beefy enough GPU these days. And without actual GPU hardware, software Vulkan emulation is good enough that it can still work. So Vulkan for that reason became mandatory and the only option for Waxed.

After lots of small play-test projects I actually managed to get an animation running with KMS, DRM, and Vulkan. I was mightily impressed by that. In my mind, if this was possible then building an entire display server was possible too, right?

Introducing Waxed Display Server

I kept the Waxed name but the meaning changed. Now to me the name meant that I'd tear Wayland off with force. Which will hurt a little, but you end up with something much cleaner and better. And that's about all there is to the Waxed name.

Waxed had to become a pluggable display server where a plugin would be the component that does the pretty eye-candy work. A plugin would be an entire desktop on its own, and in that mindset it made absolutely no sense to me that a plugin would have to re-implement work that others had already done.

Why would a plugin have to reinvent the wheel for triple buffering? Or input handling? Or DRM planes? Or even the security popup for "application X wants to use your camera"? Or virtual desktop support? It made no sense. It's developer duplication which is a waste of time by definition.

With that realization the Waxed Display Server project was born. Waxed wants to be an easy-to-use layer in the Linux graphics stack where any single person can, if they so desire, build a desktop of their own that is still very functional. Changes in Waxed become free new features for plugins. But a plugin doesn't have to accept that either. If a plugin so pleases, it can override features Waxed exposes.

By now Waxed is making a lot of progress and this is done nearly entirely with the GLM models. First version 4.6, then 4.7, and right now version 5 is used extensively. This entire site you're reading was organized with GLM 5 too.

So does this mean it's "AI slop"? To some it might. I don't give a shit about that. To me it's a superpower. But let's be clear about what that actually looks like. I'm not throwing a single prompt at an AI and walking away. I'm steering it continuously, debugging its output, catching its mistakes, and investing a lot of my own time into making this thing actually work. The AI is a tool, not a replacement for understanding what you're building. This project would be impossible for me without it, but it's far from fire and forget.

What AI enables here could genuinely change the path of Linux desktop environments for the better. It could mean the end of Wayland, which I'm definitely rooting for. And it could mean the start of many great Linux desktop environments and greatly streamlined experiences across desktops. That's a goal worth striving for.

C++ or Rust?

Initially I wanted to play with Rust for my first Vulkan experiments. As a C++ developer, the Rust way of developing doesn't really click with me fully, but I wanted to try. It's the new hype after all. I spent weeks learning and playing with Rust, getting things to work here and there.

Unfortunately, when I added AI into the mix with Claude Code (at that time using GLM 4.6), the Rust bits were continuously giving me errors that I had no intent to further explore. I wanted to do rapid development, not snail's pace debugging of borrow checker issues I barely understood.

So I tried the same experiments in C++. Amazingly, it worked nearly instantly. The AI could generate working C++ code without the constant friction I was hitting in Rust. So I just kept using C++.

That said, I didn't want to write bad C++. I made my use of it more in line with Rust's philosophy: std::expected for error handling, std::optional for nullable values, and RAII as much as possible. It's not perfect, but it helped developing Waxed a lot. You get the rapid iteration speed of C++ with AI assistance, while still having reasonably safe patterns.

What's Next: LEF

Most of Waxed's core development is already done, though work on it remains very much active. Development is now shifting toward rapidly prototyping the LEF desktop to put all of Waxed's features through their paces.

The name LEF has a double meaning for me. Take the letters K, D, E and increment each by one, you get L, E, F. But I'm also Dutch, and in Dutch the word "lef" means courage. That felt very applicable for a project attempting to do what LEF sets out to do, so the name stuck.

LEF will be the reference desktop platform showcasing what you can build with Waxed underneath. The project isn't on GitHub yet because it's still moving too fast, but that changes soon. In the very near future, within days from now, I should have a Qt application running inside LEF, which itself runs on top of Waxed. That milestone will christen the public alpha releases of both Waxed and LEF, version 0.1.0. That's when things start getting real.

Check out the code on GitHub or browse the documentation to learn more.