 All right, welcome everybody. We're about to start the next talk, which is about a topic that I personally know very little of. So I'm really excited and looking forward to learn a bit about Window Managers, which is definitely interesting. So I'm very happy to introduce Raichu, who's going to talk about his self-written X11 Window Manager. And he's going to talk a little bit about his experience implementing it and what he learned on the way. So please welcome Raichu. Wow, fancy. Hi, I'm Raichu. And this talk is basically terrifying me because this presentation is given with the software that I've written. So it's an early alpha state, so yay. Pretty terrifying situation. Anyway, I'm going to talk a little bit about my experience with X11 in Wayland and implementing Hikari, which is my Window Manager slash compositor. And another interesting thing about this topic basically spawns a lot of people that have a lot of opinions. It's kind of weird that people have very strong opinions on that, but maybe I can give you some interesting maybe informed information about what's basically going on. So yeah, I said this talk is a little bit about Hikari. I'm going to talk a little bit more about X11 in Wayland. But first of all, I want to tell you why I basically started doing what I did in the last one and a half years. So I wanted to build a Window Manager for some reason and later on a compositor. So I've been spending the last one and a half years looking at X11, looking at Wayland, those different protocols, and roughly spending nine months working with each one of these. And so I've written this whole Window Manager, which basically does things like moving your Windows around, resizing them, does displaying, and all this stuff, and gives you abilities to manage your Windows. So yeah, I've written this thing from scratch, and I was largely inspired by things like CWM and Herp's Lift VM. So I wanted to have something that is keyboard-driven. So I'm of a user. I want to have shortcuts and fancy things for everything. I don't want to use my mouse, so I want to be able to do that. So fast navigation and stuff like that. And I want it to waste very little screen span. Now, I will show you what I mean to have waste very little screen space. So this is basically my aesthetic. So this is a terminal, and it has a one pixel border. And every pixel means something. So the white border tells me this window has focused. It's basically all I want to know, all I want to see. And I don't have title bars, which consume a lot of stuff, except when I have title bars. So I built something like when I press Mod, it shows me the information that I need. Like, this is like fish my shell. It's on the first workspace, and it's in the group shell. I'm going to talk a little bit about what these groups mean. And as you can see, it tells me, OK, this is the window that has focus. So this is inspired by CWM, which has this concept of groups. They can put windows inside of groups and display them independently. And you have groups one to nine. And I wanted to be able to have independent groups, because I started using them as workspaces, and which is kind of like defeats the purpose. But I wanted to be able to group windows together in an arbitrary way. So when you open another window and open another one, you can see that when I press Mod, that these frames turn orange, that this belongs to a group, and I can cycle between windows inside of a group. And there is another thing like I now started a root shell group. This is a different group, so I can cycle between the groups. So this is something that I wanted to have for some reason, and it turned out to be very much fit my workflow. So yeah, I'm not a big fan of tiling, except when I want to arrange my views. And so I built something that works like Hustl fam, where I can tile all these views and skim through them. And this is configurable. So you can write your layouts in something that kind of resembles JSON. It's UCL, which is the universal configuration language, which is used by FreeBSD, by the way. Yeah, and this is basically what drove me to do this. And I also wanted to have minimal dependencies, have a very slow set of libraries that I'm using, and I want it to be energy efficient. I try to be as energy efficient as possible, because yeah, it saves a lot of time. It gives you a lot of time with your computer, because battery time increases drastically. And also I wanted to talk at FreeBSD, because that's the operating system that I'm using. I will, at one point, support Linux and other operating system, but right now it's FreeBSD only. Yeah, so it has those two implementations. I wrote this thing basically twice, which spent twice the time on one thing. Why not? Yeah. So what were these different approaches? So we basically have X11, which most of you people probably know, and then we have this new thing, like 10-year-old Waylon. And both of these things are basically protocols, like TCP. So it's a protocol that somewhat describes your application. I want to look like this. I want to work with events in a certain way. And there are certain implementations, like the Xorg server. And there's also this Waylon thing that I'm going to talk about. But first, let's talk a little bit about X here. And the X window system, which is the implementation that most of you are probably using, when you're using recent GNOME, which is Waylon by default. So let's see a thing that looks like this. So we have the kernel. We have this kernel mode setting stuff. We have FDF, which gives you keyword mouse events and stuff like that. And in the middle, we have this X server. And it's basically responsible for rendering all this stuff. And then we have a bunch of clients up there. So this could be your terminal. This could be your screen locker. And your window manager, because your window manager is basically just a client to the X server. It's kind of like that. And this step is optional. This is what recently, maybe like 10 years ago, I don't know, even more 15 years ago, they added this compositing thing. So when you press a button to generate an event, the X server figures out what client it goes to, sends that one to the client. The client does things. It figures out how it wants to look like, sends this back to the X server. Then the X server sends things to the compositor. The compositor munches everything together and brings that back to the X server. And the X server basically displays all this stuff. So we have a lot of things going on here. And yeah, you can see there are a lot of processes involved and a lot of communication between all these things. So what does a window manager look like? This is like the most simple implementation that I've found. It's a tiny WM written by Nick Welch. And it fits the slide. I don't know if you can read that, you shouldn't, but just to give you an impression of how easy it is to getting started with a window manager. I basically had my first working implementation of Ikari after a week and I started using it on a daily basis after that, which I think is kind of impressive because the platform gives you so much or so many mechanisms that it provides that you basically have everything in your X server and yeah, get a lot of the stuff for free. So now I want to be able to talk to this. I said talk to the X server. I said it's a protocol. And there are different ways to speak the X server. And the old way, like the old people did, it's called XLIP. And all these API calls are pretty synchronous. You write a request, then you wait, then you read the response and over and over again, you do that so you can see you waste a lot of time waiting. A lot of applications are really waiting like a long time before the X server response. It's kind of annoying. So people came up with XCB, which is the foundation of a lot of things that XLIP is basically built around this XCB thing. But with XCB, you can write, write, write, right? Then wait for the responses and just consume all of these responses, which is a lot faster. And I went with this XCB and it gave me a sort of really fluffy window manager feeling compared to others that were using XLIP. So yeah, I went that way. So now I want, I have to pack a lot of stuff so hopefully I'm not going too fast here. So I want to talk a little bit about the, some interesting things that I discovered when working with X. So let's think about how I order windows in a stacking window manager. So I basically put them on top of each other and then the X service render them. Certainly you need to have some sort of ordering there in which order the window, the DX service rendering them and you want to cycle through them. So these, I have this concept of these groups that I showed you and the X service no idea about them. So it doesn't know when I say go to the next window, I couldn't do that because it doesn't know what groups are. So what I had to do is essentially I had to reimplement all this functionality in my window manager and synchronize them. The X server now has an ordering of windows and my window manager has an ordering of windows. And I'm not the only one doing that. Basically every other implementation I looked at of the modern, modern window managers, they are all doing the same thing. So I had to reinvent the wheel basically which is a bit annoying. And that was another thing. Just think about, I want to move this window to up. The thing is that the X server basically it has just one giant buffer and then your client just sends some primitives to the X server and it draws things there. So it just draws this in one buffer. And maybe you've seen this. If you raise this window, then this portion of the screen needs to get redrawn. And so what the X server does is it sends an expose event to window two, to the client of window two. And then it generates all these primitives like write a line, draw a circle, and draw some text over there. And it just redraws them. And so sometimes you really see this effect where when your computer is on power management that you can watch it redraw itself. And that's kind of like learn to accept that. But it gets better with compositing. But it's still not pretty. It's really something that annoyed me at some point. And with modern two kids, it's even like they basically draw everything into a PIX map and hand this PIX map over to the X server and say, draw this. But don't touch it, just draw it, please. And you can think about how much traffic you can generate when you have this giant PIX map. And on my screen resolution, one frame of the entire screen will basically be like 10 megabytes. And let's talk about network transparency here. That's an interesting thing to think about. But yeah, this is basically what happens. And this was kind of annoying thing with X that I uncovered. And another thing. So this is code from, I don't know if you can read the comment. This is code from Awesome that I saw. Before I said that the X client is the X window manager, the window manager is basically just a client. And sometimes I had to ask for a keyboard. Like when I open a view and I want to change the group it's in, then I want to be able to type stuff here. And so I have to grab all those keyboard inputs and it goes I want to get all the screen events, get all the keyboard events and write that into a buffer. So this is something I saw in Awesome. And Awesome is basically like begging the X server, give me that keyboard. It's doing that for 1,000 times, then it waits for a millisecond. So it basically tries for a second to please give me that resource. Even though the window manager should be the thing in charge, it's basically begging for resources. And this felt wrong when I wrote it. But yeah, it's also what most window managers seem to deal with here. That's a problem when you have a middleman. Yeah, and this is so with the conclusion of when I implemented this in X, I basically said, OK, wow, it's really easy to come up with a window manager. It just takes a week to get something roughly working. And yeah, but all these graphical user interfaces, they kind of evolve. They basically all do off-screen rendering, then just shove around PIX maps and stuff like that. Maybe there could be something better. You have a gazillion of extensions. That's also fun. Because at one point, you will discover a client that will use an extension that you never heard of before, and it will do something weird, which is also fun. And then you have to look up in all these other window managers how they are dealing with it. And it's not pretty. And X is a global namespace. Every client, at every point in time, can become a key logger, can become a screen recorder, and just send your stuff over the wire. You can have a lot of fun with that, believe me. So from a security standpoint, that's not good. Yeah, the window manager is the client. It has to back four things like the mouse or keyboard. And you also duplicate a lot of functionality, and you have ugly screen artifacts. So I was basically a bit fed up with this and thought, well, there is this new thing called Wayland. So why not look at that as well and see how that works? So this is the architecture of Wayland. And we basically just take out the entire X thing. And now we just have clients, and all these clients do upstream buffering. And now the client just said, hey, use this buffer. And we all use shared memory here, so it's not going over the wire or anything. Like just write into this buffer, and then I tell the compositor, please display this. And the compositor takes care of all the input events. So I don't have to back for my keyboard anymore. The compositor controls it, which also makes this from a security standpoint is a lot more interesting. Because now you can say, OK, I will just deliver this keyboard event to this client. The other ones don't see that. And the other ones think they are perfectly the only things that exist in the universe. Like this is real UI is isolation. You cannot build something that records the content of any other screens, which is pretty awesome. And every frame is perfect. This is really something that came to me pretty early. Wayland really evolves around the notion of a frame. It's like the compositor decides when to redraw things. It's not like draw a line, draw a circle, draw some text. And in between, I could just draw a frame and flicker and do screen tearing and all this stuff. This just doesn't happen with Wayland. Everything is super smooth. You don't want to go back when you see that once. It's pretty impressive. And there's also stuff like damage tracking. And if you want to read more about how Wayland and Wayland compositors can do things, I really encourage you to read that blog post by Emerson. Probably butchered his name, sorry for that. But that's really interesting stuff. I have to hurry a little bit here. So how did I write this thing? Obviously, I need to be able to write this Wayland protocol stuff. So I chose to use WL Roots, which is the foundation for Sway, which is basically I3 for Wayland. And it's like the 50,000 lines of code you need to write anyway. So I thought, yeah, I don't want to write those. Thank you. And I used that thing. And it's basically now, for a lot of compositors, it's the foundation. And it's very well-written stuff, so you should check that out. But it was released after I started working on the X implementation, so no harm done here. And they want to look at the most simple Wayland compositor that they can look at, tiny WM. It ships with WL Roots. It's around 1,000 lines of code. That sounds like a lot, but keep in mind, that's a compositor, that's server, and a window manager, like three things in one. And Cache is also something interesting to look at if you want to learn, have different resources. It's like a kiosk thing for Wayland. It's also used WL Roots. And basically, all of these two kids that you see, they all support Wayland out of the box. Save your client, written in GTK or QT or Clutter, whatever that is. I'm uneducated, I don't know. NSDL, they all have Wayland backends now. So you can basically, transparently, switch to all these things without even noticing, which I found was pretty neat. Firefox words, Thunderbird words, just set this environment variable. It's a bit flaky at times, so I'm kind of glad this thing didn't crash. It doesn't crash that often, but it could happen in the worst of times. There's MPV, a video player, and WL Clipboard makes my NeoM happy. And if you want to be able to have X applications, you can do this with X Wayland. So yeah, I had to hurry here a little bit. Basically, it's a lot less complexity and looks way better. There is a lot of cool stuff going on there. Yeah, I have roughly around the same amount of code here, which I think is pretty neat because it does so much more. You have more responsibilities, things like stream lockers. You have to implement that. So now you wonder, what kind of programming language did I use to implement this? And this probably divides the room into yay and ooh. But I basically did this for good reasons. Like I said before, it's 50,000 lines of code C. And there were other people trying to do that in Rust. And they basically said, OK, it's too hard. We can't do that. This is from the Way Cooler compositor, which is awesome in Wayland. And they basically said, OK, we can't do this. It's too much work. And I don't want to rewrite 50,000 lines of code in Rust. I basically don't have the time for that, even though it will be probably interesting to do so. So yeah, I did address sanitizing. This is a very cool thing to check your if you have things like double freeze or use of the freeze, ASAN is pretty cool. And I used a lot of detrays. I can show you the strip later on that basically keeps track of all the memory allocations that I have so that I can look at memory. So yeah, it's basically if if you want to get a hold of me on our Mastodon, I'm on Matrix. You can write an email to me or just join our Hikari chat room or get in contact with me at the Ekmail apps assembly. Thank you. Right on time.