Insaturé

I hate every single line of xwayland code I wrote, it is ugly, long and hard to maintain. Now I know very well why there is wayland in the first place, sadly a complete wayland compositor has to bring a piece of crap of X with it. I just finished the selection handling in xwayland by mimicing weston code. After finally understand that 1000 lines of confusing code, I just found out I can’t do any better.

Folks, the Magical year of 2020 is behind us, and it wasn’t a happy new chapter waiting us. Man, I still couldn’t believe, once per 100 years, why it was us who have to face the coronavirus. Now I take a good look of my 2020, I went from trying to submit a xcbcommon handling patch to weston to writing a full wayland compositor from scratch. It was not my plan!!! Taiwins should have being a rather simple application on top of the libweston, the so called “reference compositor “, but libweston cannot change keyboard layout once launching, nor it can support cloning output, there are new bugs when you digging deep. The worst is that it breaks the library into different shared modules, and changes lib location every release. It was like it really does not want to link to it. The codebase was old and long, it was difficult to make a change and really difficult to get libweston taking a patch. Then there is the wlroots. If it was released half year earlier Taiwins would probably sit on top of that. But, screw it. I am doing it myself.

In the first blog of libdrm, we went through the repainting loop using the libdrm. Now we move on to the topic of framebuffers. A framebuffer is a piece of memory (could be on main memory or on GPU) for repainting every frame. It is like a canvas, represents what you would finally see on screen. Framebuffer is already a familiar concept to rendering programmers, in OpenGL, We have GL_FRAMEBUFFER_0 for presenting the surface, additional framebuffers for roles like G-Buffer and post-processing. In GPU programming, framebuffer is also a broader concept, “abstraction of a collection of attachments”, the underlining attachments corresponds to actual pieces of memory we talk about here.

As the taiwins project finished with X11/Wayland backend rigging. Now I am fully on the libdrm backend development, dealing with hardwares directly. This backend requires 200 percent my energy to tame the complexity.

Like other backends, libdrm also needs to provide two resources, input and output. Backends like nested wayland backend or X11 backend, the output device are the windows created by ourselves (or by the user). Meaning we can create it or destroy it as we please. As for libdrm, those are provided by the OS. An output in libdrm’s terminology, is called connector. We query and change the connectors state by drmModeGet* functions. Then later set the hardware states by drmModeSet* or the new atomic API. It may sound simple but actually, for displaying images on the screen using the libdrm mechanism, it takes quite a few components, working together, to achieve the goal. We uses drmMode* routines for kernel-modesetting; libgbm for framebuffer allocation; OpenGL or Vulkan for rendering. If done right, you would get tear-free images on your screen constant refresh rate. But should anything goes wrong, you probably end up with a black screen.

It is a sunny day, somehow I got up early this morning. The cool, chilling breath of air reminded me we are at the tail of the summer. It felt so strange, this summer was like it was never here. Hiking, go swimming, taking a trips and night outs. all those experiences for a normal summer I would do, they are all absent, hope I don’t regret too much for crunching code at home all these months. It was a tough year actually, I was determined to push Taiwins to a usable state, it has been stressful. Every time I look at the pile of the TODO list, a sentiment of endless development and desperate hit me hard like a heart attack. I had to work a lot to stay healthy.

July, the hottest month in Montreal every year. The heat wave rushes to you when you walk outside makes you wondering if you are in some tropical island, it sure doesn’t look like living at 45 latitde northen hemisphere. Last month was a rapid leap towards wayland objects implementations and now I just hitted the wall of xdg-shell protocol. Today I’d like to talk about what it is like to implement a wayland protocol.

Montréal is hotter than ever in this month, under the broiling sun, it was an exhausting quarantine. The first month I remeber I was feeling fortunate I got this aleatory chance for advancement of taiwins in this global pandemic, right now all I felt was the painful experience converting all the Taiwins server code away from libweston. Implementating of server side wayland objects was indeed unpleasant experience. Without libweston, I have to implement every little thing and get it right, even the basics 2D homogenous matrix operations for coordinates transformations. Just a days I ago I discovered my mistakenly used rotations in the “Y-up” coordinate system (like OpenGL) in the “Y-down” coordinate sytem (like Wayland protocol). The good news was that I did not give up, it seemed I overcame one difficulties after another, now at least I can paint my taiwins shell objects using a primitive renderer. In the end, hopefully I will end-up with a working and cleaner compositor library than libweston. This is certainly an encouraging news as I used to think a compositor library was not possible to finish with only two hands.

You need a wayland compositor library to create a wayland server. Wayland is a protocol, itself, cannot do much, long time ago I used to think the server-side wl_resource represents some structure you can operate on, well it turned out all you do with it is handling messages between client and server. All the logic you need to implement yourself.

There were a few attempts to wayland compositing library created. The first sucessful one is wlc. I think its existence is that weston (the twin of the wayland project, now maintained by Pekka Paalanen). was a monolith application for a long time. Weston looks pretty and quite fast and beautiful but not very useful to anyone else. The developers maybe realized that they want to get more people to use weston, so they managed to strip libweston out of weston itself. It was a good attempt, although I doubt their true intention was to creating a reusable compositing library. Nonetheless, to some extent, it helped the birth of the third library by Drew Devault, the wlroots.

wl_data_device interface in the base wayland protocol is the most complex one, in my opinion, wayland.xml explains it fairly well, but every pieces are scattered in the file, here I serialize it together, give you quick run through.

In brief, data device in wayland consists of four interfaces: The first is wl_data_device_manager, it is the global. The second is wl_data_device, can be created from wl_data_device_manager for a given seat, it is used to set selection(ctrl-c ctrl-v) and drag-n-drop. The 3rd is wl_data_source, also created from wl_data_device_manager, this source will be either a selection source or drag-n-drop source. The last is wl_data_offer, which is used for copying data from wl_data_source.

Forcing a monthly blog update seems to be a good idea, giving myself a reason to keep paying for this Domain. Also, I don’t usually has a topic to address specifically, a monthly update can fill this role. Anyway, time passes rapidly in quarantine my friends. I hope a few years forward when I look back at this moment, I would not feel I wasted so much time. I don’t actually feel I made much progress through this month. I would say, I am digging into my memory right now, it is hard to recall much in detail. yeah, that is life in quarantine, “stagnation”, like the blackwater.