 30 seconds extra. Nice. So hi everyone. I'm Raichu. I'm going to talk about X11 and Wayland and unlike the link to this talk, it's not about porting Wayland. It's also not about this window manager slash compositor. It's basically about how I got there and all the little hurdles that you have to take when you're doing this on FreeBSD. We heard this from Nia from NetBSD. Now, same thing for FreeBSD. So yeah, this is basically just the hackspace that I'm at, so don't care about the other. So I basically give this talk at 36 C3 before. Now I have 10 more minutes and I don't have to rest that much, which is good. So first of all, what was my project? So the project is called Hikari, which is a window manager and a Wayland compositor. So I thought, why not just take twice the time for a project and re-implement the thing using two different protocols? So yeah, that was fun. So I roughly spent six months in every technology, so I can kind of like, I think I can form an informed opinion about this, so maybe this is useful to you. So first of all, why did I do that? So why do you write another window manager, another compositor, planning out there? So yeah, basically I wanted to write something that's sort of like a stacking, tiling, window manager approach. Anyone know CWM from the OpenBSD folks? Yeah, the OpenBSD everyone. So that is something that I was using on FreeBSD before and I thought this was a pretty nice concept and I wanted to have something a little bit more, I thought this idea of groups was very intriguing because CWM has groups one to nine and I basically just started using them as work spaces, which is not really the idea of CWM, I think, but I thought this group concept was pretty intriguing. So having arbitrary groups was probably, this was something that I wanted to have and I'm going to show you what I mean by that. So this is, let's start a terminal. So this is basically just a simple terminal. This is my aesthetics, like one pixel border. I'm happy with that, every pixel means something, which I think is a nice thing. So this is now white border. I know I have context. Focus. So this concept of groups, I have two terminals now and they reside in the same group. It's the root shell, it's the shell group. So when I press mod now, I get my title bars and it shows me all the windows that belong inside of that group. So you can see, okay, this is my fish. We're on sheet two. I use the word sheet for work spaces, kind of different semantics, but anyway, I won't go into that here. And it's in the shell group. So I wanted to be able to, like, arbitrary group windows together. So I have a communication, web, video, audio, shells, and also maybe something like root shells. So this is a root shell. I'm not going to type in my password here. You can see this is a different group. And what I can do now is I can cycle just between the most important views of the group. So to me, that was something that I really wanted to have. It's kind of useful. And as you can see, this is like the usual floating thing, which everyone thinks is totally inefficient, but I don't think it isn't. It isn't. But sometimes I want to arrange my views. Sometimes I want to have tiling. And so this is a very basic tiling algorithm that I used and was kind of inspired by what Habsluft VM or everyone wants to pronounce it does, where you can basically split up the screen into different sections and different frames and use different tiling algorithms, like grid, vertical, horizontal, full screen, and stuff like that. And you can configure that in the configuration file and kind of looks like, it kind of looks like JSON. I'm using the UCL configuration language, which is something that the FreeBSD folks are using as well. Internally, so I thought, why not use that as well? And as you can see, I only have my title bars when I press mod, which is kind of nice because I think title bars really take about a lot of screen escape. And sometimes I want to see what the title of the window that I'm currently at is. So that can be kind of useful. And I want to have a very keyboard driven workflow where I can jump to different windows just using like shortcuts and speed dial things. It's kind of useful. Yeah. And I also want to have minimal dependencies. I know this is something different for everyone, but I just depend on a couple of things like Cairo, which kind of spoils it for some of the people from OpenBSD that you can't pull that into base. Sorry. Yeah. I just need to have something to draw, and that was the first thing I thought. And I wanted to be kind of energy efficient. So I was in CWM back then, and that's a very minimal window manager. And when I switched to Wayland, I suddenly had one hour more of better life. It was like, okay, this is interesting. What's going on here? So I wanted to investigate more. Yeah, it's obvious that I talk at FreeBSD. So yeah, at one point, I will try to support other operating systems, but I don't have that many computers and don't want to go into virtualizing everything. But I will go there. I will get there. First things first. Yeah. And I have two implementations because I spent twice the time on a project. Why not? So yeah, what's the difference? What was the different thing that I felt, the different problems that I encountered? There is an X there. I don't know if you can see it in the back, but yeah, that's X or versus Wayland. Basically, those two are just protocols. We always talk about are you running X or whatever. And X is basically just a protocol that we speak and then an application space that draw me like that. Draw me like one of your French windows. I don't know. And also, Wayland is also. Those are just protocols like TCP. So how do we manage events? How do we want to look like whatever? And this is what these two things do. So let's look at X first. So I stole these from the Wayland page. So this is like the situation you have with Wayland with X. This step is sort of optional. And what happens? First you press a button. You generate an event. You send it to the X server. The X server figures out what client it sends this event to. Like the terminal or your lock screen or your window manager. Window manager basically is a client to the X server. It's like any other program. So it sends it there. Then it, this client replies what it ever like I want to look different now or I did something and communicates this back to the X server. And when you have a separate process like Compton, it basically sends that all this stuff over to the compositor. The compositor does something, overwrites everything that the X server does. And yeah, so there's a lot going on here. And you can see all of these different processes. A lot of context switching, a lot of work that the computer has to do just to talk to, just basically when you're pressing a button, like hell breaks loose. Yeah, and as I said before, your window manager is also just a client. And this becomes interesting in the future, spoiler alert. So yeah. What does a window manager look like? So this is the most minimal window manager I could find on the internet. It's called Tiny WM by Nick Welch. And it basically fits on a slide. I don't expect you to read that. You shouldn't. But this is, I just wanted to show you how much work it takes to really get something working. And this is what I found. It was kind of impressive because after a week, I had a working window manager that was like, oh wow, this is kind of cool because in the X server, you have all this functionality. Everything is ready for the taking. Everything is already there. So yeah, why not just use it? So I thought, well, this is kind of neat. Well, maybe this X stuff isn't so bad after all. And now that we know our window manager looks like, we want to figure out how to speak to this protocol that I was talking about. How do we speak X? And there are two ways to speak to the X server. The first one is like the traditional way. It's called XLAB. And it's very synchronous. So you talk to the X server, then you wait. Then a reply comes. Then you do something. And as you can see, you write the request, then you wait, you read. And this blocks a lot. And you can see that in some of the window managers that are basically using XLAB that it's not as snappy as you would like it to be because why would you just write, request them and wait for the answer. Maybe you don't need that immediately. Maybe you want to write a couple of requests and then later consume the responses. And this is basically what XCB does. So XCB is the XC binding which is sitting underneath the XLAB. And we can talk to that directly. And now we can just write all these different requests and then we get the responses. And this is really making a difference. So with my first implementation of Ikari, I was comparing this against CWM all the time, that felt way snappier. That was because all the stuff that I saw in CWM, maybe they are using XCB somewhere down the stack, but I don't know. They are using XLAB. And you can really sometimes see when you're switching between groups, it takes some time until everything gets redrawn and it's kind of annoying. So let's talk a little bit about how the XLAB draws things. Because obviously when you draw windows, you need an order in which you want to draw them. So we usually draw from top to bottom. And most of the time this is also your stacking order in which you want to cycle through the windows. So you just go up and down the stack if you're using a stacking window manager. And yeah. So this is the first place where I got a little bit, okay, what's going on here. Because when you have this, I showed you this group thing that I had. I can group windows kind of differently. I want to cycle between groups. And now I have some sort of ordering inside of my window manager that the X server knows something about. And kind of like when you look at other window managers you see a lot of them are re-implementing this functionality. How do you order your windows? Basically everyone's doing that. So the X server knows has an order in which it draws the windows. And you on the window manager side have the order in which you want to cycle them or stack them or whatever. So you are basically having this thing in two places. Which is kind of annoying. Because you have to keep them in sync and things can go pretty bad. Another very fun thing that I just started another terminal. And you see these borders there. These orange borders that are drawn over the other window. And X you're doing that in a very, very ugly way. Because basically every line there, and I didn't make this up, other window managers are doing this as well. This is a window, this is a window, this is a window and this is a window. And you just give it a background color. So Openbox is doing that. I was doing that as well. And when you have a stacking window manager you always have to keep those on top. Which is fun. It isn't. Can be pretty frustrating. So yeah, that was the first thing I was like why do I have to do that? Annoying. And another thing that you will see pretty quickly when you're not running things like Compton is screen art effects. So imagine you have this window too. And you want to erase it. So we do that. We probably need to redraw this part of the window. And what X does is like it sends an expose event to that window, to that client, just like an expose. Please draw yourself. Show me how you look like. And if you're running on power management or something you can watch the window getting redrawn and we sort of learn to accept that. And it's kind of funny when you draw a window over other windows. You get this nice little Windows 95 effect. It's beautiful. Modern art. Yeah, this was really, I mean gets a lot better when you're doing compositing and things like that, but well, when you do compositing your clients still have to implement that functionality. Your libraries at least have to do that because you cannot depend on the fact that a compositor is always present. So yay, useless code lying around there. Yeah, so things are getting like pretty weird. So they're handling expose events when you don't need them. Yeah, it's weird. So go back to the, mentally go back to the thing where I told you that we had that every client is every window manager is also just a client. That means that the X server is basically handling all the events and stuff like that. So your window manager is just a client, so it has to ask for events. So when I do something like this and I want to put that in a different group, oops so now this one has input and I can do type type and all the stuff. Now my window manager compositor just wraps the events and you type in there and all the all the events get sent to my compositor instead of client. So when I'm in X I have to fight for the right to process input events and this is how awesome does it. Awesome basically just tries a thousand times, please give me that keyboard. I am the window manager I am in charge, please give it to me. And waits tries again and for about a second you're, I mean the awesome people they know what they're doing. But yeah, this is fun. I had to implement this myself and it felt wrong. I don't know why exactly I don't know why it felt wrong but yeah this is like you are in the window manager should be in charge but now you're just please give me resources because I really need those. Yeah, fun stuff. So yeah, so this was my journey into the world of X as you can feel I have some issues with there but it was very easy to get something up and running like having a working window manager that you could use in your day job after week is like yay feel pro hacker but you assume it works nice. But yeah, roughly you have interfaces also have evolved and you have tough screens we have things that can rotate for some reason and also toolkits have evolved. You have things like off-screen rendering and buffers that get flipped around so things look smooth and you also have those nice extensions of protocol extensions that you usually stumble in when you're trying to start Firefox which Nia also mentioned is doing interesting things with a computer. Yeah, that's also fun when you start a client that's using a protocol that you never heard of before and things started look weird and windows jump around and resize themselves for weird reasons, yeah. But the main problem that I'm having is X is a noble namespace so every client at every point in time can just turn into a window key logger or a screen recorder and just send that over the wire because like in every window even knows where it is on the screen why? I mean this is weird and you're duplicating functionality and you have screen artifacts and all these things that we've kind of learned to accept but yeah. So what's this other thing like Wayland? I actually started with them looking into that and people started bugging me would have Wayland's board I was like nah, I'm going to use things that work like X yeah past me I don't know what was wrong with me back then and I also saw nice little screen tearing effects when a friend of mine was using my window manager and started in Firefox and it wasn't fun it looked like I'm not going to say that. It looked not good but yeah this is the situation with Wayland you can see it's a lot more cleaned up because now we have the X server the display server the window manager and the compositor it's all road into run process so you're not jumping around a lot anymore and that also really makes a difference. Context switches especially because Intel has done such amazingly great work with things that have become quite expensive yes and this really helps and now what happens now with your client basically just gets surface and it just draws stuff in there and tells the compositor please use that so we're automatically using a shared memory model which is nice because now we can have things like the client can have stuff like buffering and so smooth transitions and stuff like that most libraries do that you don't have to care about this this is great you can get this for free and yeah now Neil said that you have stuff like screen lockers like I said before screen lockers is a really weird process because you start an arbitrary process and now it gets all the input events okay I cannot see how you can exploit that well yeah anyway but now the compositor has a lot more stuff to do actually I'm doing screen locking in my compositor which is also nice to kind of can turn up the screen stuff like that and save energy which is also neat these days but yeah this is how it looks like with Wayland and yeah every frame is perfect everything in Wayland evolves around the idea that frames should be quite perfect you don't have screen tearing, you don't have things when you're scrolling, things are starting to look weird or expose a window and then you see just half the window and watch it get itself redrawn which is super annoying but I just wanted to show a demo where I demo all this damage stuff basically my compositor only redraws the things that the client tells it to not currently running, there's not the debug version so I can't show you but it's actually kind of nice when you just start this and you type into a terminal and the only thing that actually gets redrawn is like the part where you're typing this is pretty neat, you're not just redrawing everything so but since we're using this double buffering stuff we really just the client says okay draw this and we just flip buffers and stuff like that but you have to take care that this works correctly because you can have very interesting artifacts when you're not telling you should redraw this part of the screen you have to take care of that then compositor but thankfully you can read this blog post it's by one of the authors of the WL Roots library how this works but basically the library that I'm using is taking care of that so what library have I been using so I've used the WL Roots library yep, that's clean 10 minutes left so I'm using the WL Roots library which is 50,000 lines of C code that I had to write myself and I didn't want to do that so thankfully someone else did it's the foundation for Sway which is like I3 for Wayland and probably one of the most popular just standalone compositor that's not embedded into a desktop environment and it reached 0.1 in October that was after I started working on the X thing so yeah, I came early to the party but not before it was it has its first stable release and it's now the common ground for a lot of compositor Sway is using that cage which is a little kiosky thing which is also an interesting implementation that you can look at probably one of the most minimal things and there's tiny WL which is shipped with WL Roots which is the really smallest use case that you can have and it's just like a thousand line of code while the other one fit on a slide this is a thousand lines of code it sounds like much but remember compositor is everything in one process so I think a thousand lines of code is actually kind of nice yeah and some things that when you're starting to run one Rayland, most of these libraries that we most of the use and like GTK, QT, Flutter and STL all of them already have Wayland backends so you don't have to care about this just start a process and it just works so I'm using Sakura which is a very minimal GTK terminal and I didn't have to tell it anything it just starts and it's already using Wayland because it sees there's a Wayland process I can just use this back end now and what you see right now is Firefox natively running Wayland my compositor currently X Wayland support is a bit broken for me because I'm not maintaining it anymore I'm just using native Wayland clients at the moment probably need to fix that in the future but yeah you can pretty quickly replace everything with Wayland native stuff and you don't have to care about X anymore which is kind of nice and you also have clip art stuff that makes my Neovin happy video, Firefox, if you're using Thunderbird you just have to set this environment variable and everything starts to work which is pretty neat I don't see a lot of weird stuff happening so yeah it's this was what this felt like but it was harder to get something up and running it took me like three or four months to really feel confident enough to use it at daily work which was way more work than a week of course and the final product that I'm having right now even though it's more powerful it's roughly the same amount of code that you have there which I think is also kind of neat a few processes that aren't involved like I said the nice thing about this is that you are really really saving battery life there and you have true UI's isolation which I think is really awesome every client just thinks it's the only thing on the planet so this is one of the buffers of another client which actually is very interesting security issue there that this can happen that everything can become screen recorder there are protocols that you can implement to implement something like a screen recorder or implement something like screen locking this exists but I don't know how standard it is because I think it's part of WLRoot and it's not standard it's all WLRoot stuff you have direct control over your stuff oh I have to fight for input resources and stuff like that control over frames, don't know flickering sometimes client side decorations get a little bit in the way because this is what a lot of clients are doing they have their own borders and you have to take care of that as well it's a little bit weird but you have more responsibility in the compositor, things like screen locking reporting but generally I think it's a really really great opportunity for us as BSDs to catch up with other operating systems in terms of how things look like we can really seize that so yeah I was using C to implement this and so one side of the room is basically going yay the others is going blah and for good reason I can sympathize with that because why would I do that why do you know Rust this was everyone that was asking me and there was this Way Cooler project they sadly sadly stopped working on this but they started with Rust then they rewrote everything in C and now yeah now they stop working it's really hard to wrap like Nia said it before those are C APIs wrapping this in another language is why this is more work than I want to do I want to don't want to work with this extra work and I don't want to re-write WROADS completely by myself I don't have the capacity to do that so yeah I copped out and said okay I'm just going to write that with C and obviously everyone wondering okay memory leaks stuff like that ugly things are going to happen yeah basically threw everything at it that I could handle so I'm using Clang and all the sanitizing stuff so this helps me to deal with things like double free and use after free and this really helps a lot and I also have since I'm running on FreeBSD I also have detrace I can track all of my memory allocations and can see when again free this is very useful so I kind of like think I don't have a memory leak at the moment I think C is always there to surprise me but yeah I'm trying to take care of this so yeah that's pretty much it if you want to talk to me I'm on Mastodon KL Social or Matrix or you can send me an email and I have this little chat I don't know if you can see that it's akari at akmila.space which is also a matrix chat and you can also come to our Hack Space and talk to me there but yeah it's in Bielefeld, Germany so if you want to come there hack on stuff Hack Spaces are just basically hacker communities people hacking on stuff and this is one of the projects there even though I'm currently a new maintainer so yeah I'm open for questions now thanks you said in the beginning that you think makes no sense for a window to know its position on the screen as a user like I see for instance I think K-Win has this issue where for the Wayland parts they're not able to show these menu from the title window title like the main menu and on x11 it works you just click and it shows exactly on the position you clicked because it's inside the window but on Wayland they're not able and I think they said it's not possible because the window doesn't know position I don't entirely know what you mean but I can probably look at it we have one minute left so this will be the last question and don't forget to repeat the question so I'm not entirely sure what you're asking but maybe you should talk this off line because maybe you can show me maybe you can take one more question but yeah one more yes yes I did the same thing that opened because that would have even more stuff to care about but I was I think it's not really helping me if I have obscured the window by something else because that would just put that into another window then all this reparenting stuff would get replaced maybe you can do that reparenting I have no idea how to do that but all the other things yeah exactly I just do weird stuff but for these borders I basically did what open openbox did and looked reasonable to me but yeah so yeah thanks oh no thank you no no