Wayland and friends

22 April 2026

For the last few weeks I have been developing a Wayland compositor called howl in the vein of berry, probably the best X11 window manager I've ever used. Similar to berry, it also has a server-client architecture and lets you do stuff 'on the fly', although it's been a long way coming.

It is written in a novel library for developing Wayland compositors, named neuswc. It is a fork of Michael Forney's swc that aims to provide some features which the original does not have (double borders, for example), and it is really fun to write things with. Coupled with it is also a fork of wld named neuwld, for writing Wayland clients. I haven't had much of a fair shot at trying it, but it seems to be pretty neat too...

The journey begins

Now, coming from X11, adapting to Wayland was not particularly easy, not at all! I learned that a lot of the convenient shortcuts and crutches that Xlib/xcb gave me were just not present on Wayland (for better or worse), and the first few weeks of me using it I was confused with its inner workings, and I still am to an extent. Reading the source code of the compositor I was using at the time, tohu, left me completely lost. I did not understand what I was looking at! The feeling was not unfamiliar to me, however.

I got a lot of inspiration from reading the header, for some reason. The first thing I wanted to try and write was an xdo clone, but due to Wayland's architecture, that proved to be impossible. After a few days of talking on IRC with the developers, I began to sketch out the actual compositor code. The first big challenge I encountered was the fact that I had zero idea how to implement what I wanted to! There weren't any particular resources on developing Wayland compositors with swc, the only good resource I found was Appendix B & C of the Wayland server library documentation..!

After a few moments of messing around, I found what I needed: wl_event_loop_add_fd(). The name is sufficient to understand its purpose: register a file descriptor to read events from in the event loop. Now, this sounds very weird, but in reality, all it does is let you have your own handler for your specific event that is expected to come in through this file descriptor, and have all of that in the event loop.

Cool, we now have a way to do what we need! Now comes the hard part of actually doing it. Midway through designing the handlers on the compositor and client side, I found out that I have a giant architectural issue in my code, which I solved by simply mirroring some of berry's code. Skipping a lot of details, I now had a way to send stuff to the compositor, and have the compositor act accordingly. This is more than enough to have at least some sort of scriptability, though being able to ask the compositor for some info would also be nice...

Conversating with the compositor

Asking the compositor for some info isn't too hard either: simply send() some sort of response back over the file descriptor that we got from the wl_event_loop_add_fd() handler. But talk is cheap, how do we actually do this?

The way I did it is probably not ideal, and nowhere close to it, but it works. I made a struct containing 2 fields: whether the operation was successful (e.g. if we were able to, say, move the window or not) and a string for the response. Then all I needed to do was to update all of the commands to return this structure instead, and it was done! No, obviously it wasn't this easy, but after a fair bit of messing around I got it.

So we now have a way of fetching data from the compositor, which is a lot! We now have a way to implement most of wmutils in Wayland! There is a lot of ground to be covered, but it's all possible now :D

Numbers

The best way to identify any type of object is (in my opinion) a numeric ID. I got very used to window IDs in my time on X11 and, as a result, here I am reimplementing it in Wayland. Currently the only thing I have implemented is associating windows to IDs and listing them. For now you can't even provide ID arguments to commands, nor filter the window list by mapped/unmapped state, but it's something, and in the future I hope to have more stuff in the compositor using that.

Afterword

The https://wayland.fyi website is a lovely read. It provides a lot of resources on getting started with Wayland, debunks some myths about X11/Wayland and has a list of software written with the libraries at the moment.

I also want to say thanks to the people who helped me countless times while developing this and hyped me up :P

Have fun!