25 Oct 2024
Over the summer, I read a book on the Wayland protocol. Not a typical activity for a high school student to do, but there was something that seemed so intriguing about creating my own compositor.
Wayland is the superior replacement for the X Windowing System on Linux. X (or X11) was originally developed in 1984 and thus marks it's 40 year anniversary this year. Wayland got initially released in 2008, and in contrarily with X, had desktop usage in mind from the beginning. Wayland, in comparision to X, provides developers a simpler API to work with. It is still not an easy feat, but, luckily for me, the amazing wlroots abstraction library exists. It contains about 60 000 lines of boilerplate code that a Wayland compositor developer would have to write anyways. Instead of writting boilerplate, I could focus on the more interesting parts.
These terms tend to be used interchagebly, but there is a difference. When one mentions the term "window manager", they typically mean the part that manages window placement on the screen and the logic behind it. In Wayland the responsibilty of a window manager is closelly tied to handling user input, server-side decorations etc.., Therefore it is called a compositor rather than a window manager, even though the window managing part is still there.
After reading through the most crucial parts of the Wayland book I decided to conduct research into compositors that are developed. I stumbled upon few. Namely tinywl, of which I read the whole implementation, but one stood out - the Wayland kiosk compositor Cage. A kiosk is, in essence, a normal compositor, but one that only displays a singular client at a time. I read through the code and was overwhelmed at first. However after rereading the main function a few times I felt like I could understand and visualize what was going on. Concepts learnt in the Wayland book, even though abstracted with wlroots, were still present. The code is by no means simple, at least not for someone who has only done a handful of DSA problems and no serious projects in C whatsoever.
I figured one of the more fun ways of exploring the codebase is to solve a real issue. Since a Wayland kiosk has a lot of usages, there's quite a lot of people creating repository issues asking for help or reporting bugs.
Imagine you are building a car infotainment system that has to display just one application. This is a perfect usecase for a kiosk compositor. There was someone that was doing exactly that asking for help in the repository's issues. They have an application that needs to be displayed reliably everytime it is needed. The computer running the application is regulary turned off and on again. When the computer boots, Plymouth provides a flicker free loading experience. However, when it loads into the system and executes cage, the compositor instantly performs a modeset with black buffer, overriding the loader. Then, the loading application is shown and that's exactly what is not supposed to happen. There should be a way to prevent displaying the application which it is loading to provide a flicker free experience.
Before diving into Wayland, I had no idea what these terms meant. In short, they are abstractions above the physical display hardware. Each of these components has a specific role in the process of displaying things onto the screen. Framebuffer allows software to display pixels by writting into designated memory spaces.
To be continued...