X11 and Wayland: A tale of two implementations
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
raichoo
In this talk I will outline my journey implementing my X11 window manager `hikari` and the corresponding Wayland compositor shortly after. `hikari` is a stacking window manager/compositor with some tiling capabilities. It is still more or less work in progress and currently targets FreeBSD only but will be ported to Linux and other operating systems supporting Wayland once it has reached some degree of stability and feature completeness. This talk covers: * a brief explanation regarding differences between X and Wayland * some of `hikari`'s design goals and motivation * choice of programming language * an overview of libraries that were used * tools for ensuring code quality and robustness * obstacles * resources that helped me to implement the whole thing
 Alright, 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. So 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 like 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 makes you, 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 a M-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. 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, that'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, okay, 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's another thing, like I now started a root shell group, this is a different 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, it's very much fits my workflow, so yeah. Also, I'm not a big fan of tiling except when I want to arrange my views, and so I built something that works like Herfluffam 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 want to have minimal dependencies, like 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, with the 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 applications, 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-Windows system, which is the implementation that most of you are probably using, except when you're using recent GNOME, which is Waylon by default, so let's see, the thing looks like this, so we have the kernel, we have this kernel mode setting stuff, we have FDF, which gives you keyboard mouse events and stuff like that, and in the middle we have this X server, and it's basically responsible for rendering all the 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, you generate an event, the X server figures out which 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, this, 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's, it fits a 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, there are 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 this 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 Xlib, and it's, all these, all these API calls are pretty, pretty synchronous, you write a request, then you wait, then you read the response, and over and over again you do that, and 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 Xlib is basically built around this XCB thing, but with XCB you can write, write, write, write, 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 Xlib, 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 X 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's another thing, 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 2 to the client of window 2 and then it generates all these primitives like right-align, draw a circle and draw some text over there and it just redraws them and so you sometimes you really see this effect where when your computer is on power management that this you can watch it redraw itself and this kind of I learned to accept that but yeah it gets better with compositing but it's still not pretty, it's really something that annoyed me at some point and with modern, with modern 2, even why they basically draw everything into a PIX map and hand this PIX map over to the X server and say I'll 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 like this giant PIX map and on my screen resolution one frame of the entire screen will basically like 10 megabytes and let's talk about network transferancy here, that's 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 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 what it sometimes had to ask for the keyboard like when I open a view and I want to change the group it's in and I want to be able to type stuff here, type and so I have to grab all those keyboard inputs because I want to like 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 a thousand times then it waits for a millisecond so 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 that's a problem when you have a middleman yeah and this is so with the conclusion of when I implemented this in an X I basically said okay wow it's really easy to come up with a window manager just like takes a week to get something roughly working and yeah but all these graphical user interfaces they kind of evolve they all basically all do off-screen rendering then just shove around picks 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 and all these other different window managers how they are dealing with it and it's it's not pretty and X is a global namespace like every client at every point in time can become a key logger can become screen recorder and just like send your stuff over the wire kind of a lot of fun with that believe me so from security standpoint that's not good yeah and the window manager is the client that's to back for things like the mouse or keyboard so 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's this new 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 compositor of the entire X thing now we just have clients and all these clients to 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 right 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 okay 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 your of other 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 you know when 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 like super smooth it's really you don't want to go back when you see that once it's pretty impressive so and there's also stuff like damage tracking and if you want to read more about how Wayland and Wayland compositor can do things I really encourage you to read that blog post by a person probably butcher his name sorry for that but that's 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 just 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 use that thing and it's basically now for a lot of compositor it's the foundation and it's 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 a thousand 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 cage is also something interesting to look at if you want to learn like 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 so if your client written in GTK or QT or clutter whatever that is I'm educated I don't know and STL they all have Wayland backends now so you can basically switch transparently switch to all these things without even noticing which I found was pretty neat Firefox works Thunderbird works 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 could happen in the worst 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 time 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 oh but I basically this 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 okay it's too hard we we can't do that this is from the Way Cooler compositor which is awesome in Wayland and they basically said okay 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 in to string to do so so yeah I did and rest sanitizing this is a very cool thing to check your if you have things like double freeze or use after 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'm leaving memory so yeah it's basically if if you want to get a hold of me on our master on I'm on matrix you can write an email to me or just join our Hikari chat room and or get in contact with me at the ECMAP assembly thank you right on time you
 Alright, 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. So 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 like 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 makes you, 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 a M-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. 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, that'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, okay,  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's another thing, like I now started a root shell group, this is a different  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,  it's very much fits my workflow, so yeah. Also, I'm not a big fan of tiling  except when I want to arrange my views, and so I built something that works like  Herfluffam 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 want to have minimal dependencies, like 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, with the 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  applications, 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-Windows system, which is the  implementation that most of you are probably using, except when you're using  recent GNOME, which is Waylon by default, so let's see, the thing looks like this,  so we have the kernel, we have this kernel mode setting stuff, we have FDF,  which gives you keyboard mouse events and stuff like that, and in the middle we  have this X server, and it's basically responsible for rendering all the 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, you generate an event, the X server figures out which 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, this, 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's,  it fits a 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, there are 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  this 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 Xlib,  and it's, all these, all these API calls are pretty, pretty synchronous, you write  a request, then you wait, then you read the response, and over and over again you  do that, and 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 Xlib is basically built around this XCB thing, but with XCB  you can write, write, write, write, 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 Xlib, 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 X  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's another thing, 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 2 to  the client of window 2 and then it generates all these primitives like  right-align, draw a circle and draw some text over there and it just redraws  them and so you sometimes you really see this effect where when your computer is  on power management that this you can watch it redraw itself and this kind of  I learned to accept that but yeah it gets better with compositing but it's  still not pretty, it's really something that annoyed me at some point and with  modern, with modern 2, even why they basically draw everything into a  PIX map and hand this PIX map over to the X server and say I'll 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 like this giant PIX map and on my  screen resolution one frame of the entire screen will basically like 10  megabytes and let's talk about network transferancy here, that's 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 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 what it sometimes had to ask for the  keyboard like when I open a view and I want to change the group it's in and I  want to be able to type stuff here, type and so I have to grab all those keyboard  inputs because I want to like 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 a thousand times then it waits for a millisecond  so 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 that's a problem when you have a  middleman yeah and this is so with the conclusion of when I implemented this in  an X I basically said okay wow it's really easy to come up with a window  manager just like takes a week to get something roughly working and yeah but  all these graphical user interfaces they kind of evolve they all basically all do  off-screen rendering then just shove around picks 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 and all these other different window  managers how they are dealing with it and it's it's not pretty and X is a  global namespace like every client at every point in time can become a key  logger can become screen recorder and just like send your stuff over the wire  kind of a lot of fun with that believe me so from security standpoint that's not  good yeah and the window manager is the client that's to back for things like the  mouse or keyboard so 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's this new 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 compositor of the entire X thing now we  just have clients and all these clients to 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 right 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 okay 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 your of other  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 you know when 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 like super smooth  it's really you don't want to go back when you see that once it's pretty  impressive so and there's also stuff like damage tracking and if you want to  read more about how Wayland and Wayland compositor can do things I really  encourage you to read that blog post by a person probably butcher his name sorry  for that but that's 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 just 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 use that thing and it's basically now for a lot of  compositor it's the foundation and it's 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 a thousand 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  cage is also something interesting to look at if you want to learn like 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 so if your client written in GTK or QT or clutter whatever that  is I'm educated I don't know and STL they all have Wayland backends now so you  can basically switch transparently switch to all these things without even  noticing which I found was pretty neat Firefox works  Thunderbird works 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 could happen in the worst 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 time 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 oh but I  basically this 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 okay it's too hard we we can't do that this is from the Way  Cooler compositor which is awesome in Wayland and they basically said okay 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 in to string to do so so yeah I did and rest sanitizing this is a very  cool thing to check your if you have things like double freeze or use after  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'm leaving memory so yeah it's basically if if you want to get a hold of  me on our master on I'm on matrix you can write an email to me or just join our  Hikari chat room and or get in contact with me at the ECMAP assembly thank you  right on time  you
36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_0_59.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_60_107.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_108_251.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_252_7595.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_7596_8735.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_8736_9671.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_9672_11783.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_11784_12875.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_12876_14603.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_14604_20951.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_20952_23183.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_23184_24659.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_24660_25967.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_25968_27683.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_27684_28847.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_28848_29555.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_29556_29855.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_29856_30443.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_30444_30959.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_30960_31463.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_31464_31511.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_31512_31559.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_31560_31631.png 36c3-chaoswest-87-eng-X11_and_Wayland_A_tale_of_two_implementations_hd_31632_32061.png