Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1411 Thanks!
All right, welcome everybody.
We're about to start the next talk, which
is the one 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, you know, definitely
interesting. So I'm
very happy to introduce Rachel,
who's going to talk about
his self-written X11 window
manager.
Oh, and yeah, he's going to
talk a little bit about his
experience implementing it and what he
learned on the way.
So please welcome Rachel.
Who want fancy?
Hi, I'm Rettew, and
this is this talk is basically terrifying
me because this presentation
is given with a software that I've
written. So
this is an early alpha state.
So, yeah,
pretty terrifying situation.
Anyway, I'm going to talk a little bit
about my experience of X11
and 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 and 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 spanning
nine months working with each one
of these. And so I've written
this this whole window manager, which
basically does things like moving
your windows around, resizing them does
displaying and all this stuff
and makes 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 C, W, M and Hertzel.
Look them, so
I wanted to have something that is
keyboard driven.
So I'm a vim 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.
So you have waste with
very little screen space.
So this is this is basically my esthetic.
So this is 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
bar. So I built something like when I
press mod, it shows me
the information that I need.
It's like, This is like fish, my
shell.
It's on the first workspace and it's
in the group shelves.
I can talk a little bit about what these
groups mean, and I can see
it tells me, OK, if this is the windows
and window that has focus
on.
So this is inspired by CW M, 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 not
that these frames turn orange, that
this this belongs to a group and I can
cycle between windows inside of
of of a group.
And there's another
thing like now I started to root Shell
Group. This is a different, different
group so I can cycle between the groups.
So this is something that that I wanted
to have for some reason, and
it turned out to be very, very much.
It's very much fits my workflow.
So, yeah, I 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 houseless fam work and
tile all these views and
skim through them.
And this is configurable so you can write
your layouts in something that
kind of resembles Jason.
As you see, all of which is the universal
configuration language which is used by
FreeBSD BSD, by the way.
Yeah.
This is basically what drove me
to do this, and I also wanted to have
minimal dependencies.
I have a very small set of libraries
that I'm using and I want 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 it previously
because that's the operating system that
I'm using. I will I will at one point
support Linux and other operating
systems, but right now it's
is FreeBSD BSD 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 Wayland
and both of both of these things are
basically protocols like TCP.
So it's a protocol that somewhat
describes your your
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
the suelen 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, except when you're using
recent Gnome, which is
Wayland by default.
So let's think thing looks like this.
So we have the kernel, we have to
scramble settings stuff.
We have F2F, which gives your
keyboard, mouse events and stuff like
that.
And in the middle, we have this X server
and basically responsible for rendering
all the stuff.
And then we have a bunch of clients up
there. So this could be a terminal.
This could be our screen locker
and your window manager because your
window manager is basically just the
client to the X server.
It's kind of like that, and this step is
optional. It's what
recently, maybe like 10
years ago, or even more 15 years ago,
they added this compositing thing.
So when you
press a button to generate an event,
the server pick itself was client.
It goes to sense that once with the
client, the client does things.
It figures out how it wants to
look like census gets to the server,
then the X server sense
things. The compositor compositor
Manchester everything together and
brings that back to the server, and the
server basically displays all the stuff.
So you 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 of these
things.
So what does the window manager look
like? This is like the most simple
implementation that I found.
It's tiny w m 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
the window manager.
I basically have my first working
implementation of Hikari 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, so many mechanisms
that it provides that you basically
have everything in your server.
And, yeah, got a lot
of the stuff for free.
So now I want to be able to
talk to, as I said, it's 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 of like the old people did,
called X Slip.
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 wasting.
A lot of applications are really waiting
like a long time before the
actual response.
Kind of annoying.
So people came up with ex-hubby,
which is the foundation of a lot of
things that so excellent.
This basically built around this thing.
But with with XIV, you can
fly. Right, right, right, right.
Then wait for the responses and just
consume all these responses, which
is a lot faster.
And I went with with this Zibi, and
it gave me a sort of really
fluffy window managers
feeling compared to
others that we're using.
Excellent.
So, yeah, I went that way.
So now one, I have to pack
a lot of stuff. So I'm hopefully I'm not
going to fast forward. So I want to talk
a little bit about the some interesting
things that I I discovered
when working with 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 service to render
them. So certainly you need
to have some sort of ordering there
in which order the windows.
We know the service rendering
them and you want to cycle through
them.
So these I have this concept of this
of these groups that I showed you, and
the explorer has no idea about them.
So it doesn't know when I say, go to the
next window, I can do that because
it doesn't know what groups are.
So what I had to do is essentially
at re-implement.
All this functionality in my window meant
I to 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 limitation I
looked at of the modern,
modern window managers.
They were all doing the same thing.
I had to reinvent the wheel,
basically, which is a bit of a bit
annoying.
And that was another thing.
Just think about, I want
to move this window to up.
Well, the thing is that the server,
basically it has just one giant buffer
and then your your
client just sent some primitives
to the X server and it draws
things there.
So it just sits 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, it sends
an expose of N to Window
two to the client of Window two,
and then it generates
all these primitives like write
a line and draw a circle and
draw some text over there.
And it's this redraw them.
So you sometimes you really see this
effect where when your computer's on
power man has meant that you can watch
it redraw itself and this
kind of like learn to accept that.
But yes, it gets
better with compositing, but
it's still not pretty.
It's really something that
annoyed me at some point.
And with modern and
with modern toolkits, it's even why they
basically draw everything in her pics
map and had this pix map over to the to
the XOR events. I draw this, but don't
touch a drop to start point.
And you can think about how
much, how much
traffic you can generate when you have.
Like this giant pix map and on my screen
resolution, one frame of
the entire scenario basically 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 extra cover.
And another thing so this is code from I
don't know if you read the comment, this
code from awesome that I saw
as before, I said that
the client is the X window
manager and the window manager is
basically just a client.
And what sometimes had you asked
for a 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 after all those keyboard
inputs, when he goes, I want to
like get all, get all the screen events,
get all keyboard events and write that
into a buffer.
So this is something I saw in awesome
and awesome. It's basically like
begging the observer, Give me that
keyboard.
It's doing that for a thousand 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 charts, it's basically
begging for resources.
And this this felt wrong
when I wrote a. But yeah, it's also
what most middle managers seem to
deal with here.
That's that's a problem when you have a
middle man.
Yeah, and this is so
with the conclusion of when
I implement an ex, I basically
said, OK, well, it's really easy to come
up with a window manager.
It's 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 through
off 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 run off before,
and it will do something weird,
which is also fun.
And then you have to look up and all of
these other different window managers how
they are dealing with it.
And it's it's not free.
And X is a global namespace
like every client at every point
in time, can become a key logger, can
become a screen recorder and just like
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 go.
Yeah, the window manager is the client
that's the 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 is
this new new thing called Weyland.
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 thing.
And now we just have clients and all
these clients through a screen 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 capacitor takes care of all the input
events, so I don't have to beg 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 perfect.
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
any other screens, which is pretty
awesome.
And every frame is perfect.
This is really something that
came to reality.
Whalen really revolves 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
Weyland. Everything is like super smooth.
It's real.
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
Weyland and Welwyn compositions can
do things, I really encourage you to read
that blog post by Emerson
probably butcher this 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 well and practical stuff, so I just
use our roots, which is the
foundation for sway, which
is basically a three four Weyland
as like the 50000 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 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 implementation.
So no harm done
here.
And I want to look at the most simple
Wayland compositor.
They can look at tiny chips
with roots to 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 there's 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 use double yellow routes
and basically all of these toolkits that
you see. They all support Wayland out of
the box, save your client's
written decay or cut or
clutter, whatever that is.
I'm uneducated. I don't know NSDL.
They all have Wayland backgrounds 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 a video player and
a clipboard makes my neo am happy.
And if you want to be able to have X
applications, you can do this with X
Whalen.
So, yeah, I had to
hurry here a little bit.
Basically, it's a lot less complexity and
looks way better.
There was a lot of cool stuff going on
there.
Yeah, apps 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 screen lockers, you have to
implement that.
So now you wonder what kind of programing
language do they use to implement this?
And this probably divides
the room into J.
And Oh.
But I basically did this for good
reasons. Like I said before, it's fifty
thousand lines of Code C and
the while the 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 and Wayland.
And they basically said, OK, we
can't do this. It's too much work and I
don't want to rewrite 50000 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.
You are if you have things like double
freeze or
use up to freeze.
Sounds pretty cool.
And I used a lot of the trace I can show
you the strip later on.
That basically keeps track of all the
memory applications that I have set on
memory.
So yeah, it's basically if if you want to
get a hold of me on a mastodon, 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 main
assembly. Thank you.
Right on time.