All right, hello everybody, can you help me hear me all right?
I'm Isaac, welcome to my talk, separating the wailing compositor and wind manager.
So if you're not familiar with me already, I'm the author of the River Wailing compositor.
I'm working on it for like five or six years now.
And for a long time it's just been like a nice dynamic tiling wind manager.
But if there's one thing I've learned working on it is that people are very strong opinions about how their wind managers would work.
And in myself included, any opinions change over time.
And so I've been wanting to try out new things for myself without breaking things for this in users.
I'm going to break some things, but what this will result in is a new compositor architecture that allows people to experiment much more easily with new wind management paradigms.
I'm also a WRUS developer.
I'm very thankful for the WRUS project, because it does a lot of things make my job writing river a lot easier.
Direct scanner works great through WRUS without marriage effort on my end.
And even in color management completely for me.
I don't do any extra work or a small amount of extra glue code.
But it does a lot of heavy lifting for river.
I'm also a ZIG core team member.
The stock's not going to be about ZIG at all, but ZIG's a great programming language.
And you should check it out.
So who here has seen this diagram before?
I saw it from the wailing docks.
This is how wailing decides structure the architecture of the building.
It's a splacer of a compositor and window manager.
You really need to see this to be explained a little bit.
The name was not familiar with wailing at all.
Wailing clients are your web browser, your terminal emulator.
Everything that wants to display a window in your desktop environment.
And then needs to get input events from the kernel.
And then send a buffer to your display server, compositor.
You get displayed in the screen.
And so there's only one program that can get input events from the kernel at the same time.
And then display buffers.
You have to be one, just one programming doing that.
Otherwise there's no way to coordinate things.
And so that's the wailing compositor.
For example, gnome, kd, slay, river, classic, et cetera.
And really, this is three programs in one though.
It's the display server, the compositor, and a window manager.
And so it's making these distinctions a bit clearer.
The display server job is just rounding input events from the kernel from windows.
And then passing a buffer to the kernel to get rendered.
That's what the display server does.
The compositor is the part that combines many buffers from windows into a single scene.
And a single buffer that can be displayed by the display server.
And the window manager is responsible for arranging windows to finding key bindings,
kind of providing your user experience of how you interact with your compositor in the display server.
So before we talk about splitting the within the visitor,
we need to find out why the wind decided to combine these things in the first place.
And really, wind was motivated by combining the display server in the compositor.
It wasn't really caring about the window manager.
That's just kind of mixed in there because it was easier to do with that way, I guess.
And so I understand why wind can combine these things.
Me and go back and look at x11.
So this diagram is also taking the wind up set of course.
And it's making the points that the path that input events take to get a new buff thing running on your screen is quite complicated on x.
We start up with the kernel.
We're an independent pass pass through the EVVF API through your x server.
That's the display server.
Then there's already a problem here because the x server does not know the compositor's scene graph.
And so it can't really route this input to the right window properly.
But it can bring a pretty good guess.
And so it sends it off to an x window, the x clients.
This client will then respond by sending a render request to the x server.
But the x server is not responsible for rendering things.
And so then it has to send this request off to the compositor.
Render a new buffer and send it back to the x server.
Which can then finally get sent to the kernel and be displayed in your screen.
And this actually adds a lot of latency.
Because there's an extra round trip to the compositor.
And things just don't work quite as well because there's not much integration between the compositor and the x server with the x server.
Not being aware of the compositor's scene graph.
And the window manager here could be just another x client or it could be part of the compositor as a compositing window manager.
Which could be more common as x got more evolved.
And so way then improves on this quite a bit by simplifying things and moving everything into one program.
And so now you don't have a problem of the compositor not knowing about the, the place that we're not knowing about the compositor's scene graph.
Because the display server and compositor are one thing.
And so it's very easy for the way the compositor displays server combination throughout the input event to the right way and client.
And there's no extra round trip of latency when rendering because the quad veteran's place or a one program.
However, there's not really a need for the window manager to be combining here.
But so that's to summarize the benefits of wayland over x11.
x11 got embarrassing flickering flashing and tearing that we can get rid of with a better architecture.
And there's an extra round trip every frame to the talk between the splacer and the compositor which does not need to happen.
And wayland we have the every frame is perfect ideal.
It's possible when you're wayland programs are well written and your compositor is well written that every frame looks perfect.
There's no extra flickering or flashing or half render things are tearing.
And there's no extra round trips, the architecture works well.
And this policy or mechanism is a bit divisive in some ways.
Like people like, excuse me, people like the extra control of policy of mechanism of a policy in x.
Every program can kind of do lots of different things.
It has lots of tools and school box.
But this causes problems and lots of programs have competing interests.
If a pop up on your screen, a screen like a cannot run at the same time because the pop up is already captured all input.
From all devices and this causes problems.
So policy or mechanism in wayland centralizes the power in the compositor essentially.
All the programs can describe what they want to do and the compositors are responsible for carrying it out.
And this makes impositor authors very happy because they get the end decisions.
But this makes users less tapping some places because they cannot go on the time to write a full compositor perhaps.
And so part of my work here is to make put this power very quickly by policy or mechanism back into the hands of users.
And so the big downside I see of waysland compared to x is architecture is that writing wind and measure means writing out ways.
This place over a compositor as well.
It's never really way to get around that.
You can use libraries to help you out.
But you still have to debug a low level process component system component.
But if a crash is, we'll send you back to you.
The terminal.
You have the TTY or maybe just like brick to your computer.
I don't know.
You might need a hardware build if you read your wind and measure wrong because it's a place over to.
So where I'm going with this talk is a new architecture for wayland where we have a stable wayland protocol called river wind management v1.
And as you separate the wind and wave and compositor in the wind and measure.
The wayland compositor in this place over are still one components.
We do not lose any of the benefits we get from compared to x11.
So these are my design constraints.
Basically we don't want to regress any of the improvements that has made over x11.
Every stain must still be perfect.
We want to minimally impact latency.
That means that there should never be a round trip required every frame or every input event.
And so to implement these constraints, my wind management protocol divides the state.
The wind manager has control over into two separate categories.
First we have wind management state.
This includes wind dimensions, full screen state, keyboard focus, key bindings.
These are all bits of state that the wind manager that the compositor needs to communicate with every winder.
And so this requires synchronization with other windows.
Well, rendering state in the other hand is state that only effects the final rendered buffer.
This is not required synchronization with windows.
And this includes wind up position, rendering order, server side decorations.
The wind management protocol allows wind managers to draw whatever decorations they want.
Window cropping can also crop off the client side decorations that GTK is drawn if you want it to.
And this kind of thing, that's rendering state.
And so the core loop of this protocol is demonstrate the state machine.
This is how synchronization works is how we get for imperfection.
So when the wind manager starts up idle, then there will be some new events.
Some new window opens.
A cane binding is driven like a wind manager is registered with the compositor from window across to be maximized, etc.
Then the compositor will send us new information to the wind manager over the wind management protocol.
And wait for the wind manager to reply.
I call it a manage sequence.
And the wind manager is allowed to touch any wind management state during this manage sequence.
And so the compositor will keep running frames.
There's no waiting to render a frame here.
The wind manager will keep running frames while wait for the wind manager to reply.
Then the wind manager will automatically update all the state and wants to update and respond to this change.
And make a managed finish request.
Then the compositor will take this new state, send it to all the windows that have been changed autonomously.
And wait for them to all respond before running any new buffers from these windows.
Then as best as then once all the windows that have been active and configured and committed.
Then the windows all have a new buffer of the right size asked for by the wind manager.
Then we can move on to rendering.
And so again we will send all the new window dimensions to the wind manager.
And we will then wait for the wind manager to then position the windows.
Draw a declarations to the right size to all this work.
And finally, call them in your finisher quest.
And then we display the new state on the frame on the end buffer automatically.
And so this gives us frame perfection.
And synchronization with out requiring a round trip between the wind manager and the wind manager every frame.
There's one little missing piece here that someone may have noticed if they're painting any tension.
On the way land, windows are able to change their dimensions by themselves.
And so we've got like one little shortcut here.
If a window decides, I'm just going to ignore what the composer asks for and render this at a fixed aspect ratio.
And PV does this for example if it's floating mode.
It will just render that the dimensions of the video you're playing.
And so if a little shortcut there that allows the wind manager to respond to windows just randomly changing their own dimensions.
By adjusting the size of the decorations of the position of the windows.
And so this is the really the core idea of the wind management protocol.
This is a pretty simple idea.
In fact, this state machine was already hiding inside river before I implemented the wind management protocol.
This is the common state machine shared by many composers.
And I think formally specifying it allows people to reduce the amount of bugs.
Because early versions of river did not do a very good job of implementing the state machine.
And as I learned more about wind development and got better at making everything perfect.
My design got closer and closer to this ideal.
And now that I've formed, I'm kind of realized that this is an ideal.
I'm kind of training towards.
I've specified the state machine formally in the protocol.
And wow, anyone to implement their own wind manager on top of it.
So let's talk a bit more about the motivation for this whole wind management protocol.
The main goal is just to make wind and wind element is significantly easier.
It takes only 600 lines for me to write the wind manager.
I'm using it right now.
I'm using this protocol to display this frame to you right now of course.
I'm daily driving it myself for a couple months already.
And it only took about 600 lines of a high-level language to write the wind manager.
I'm comfortable daily driving.
It's pretty much as beautiful as what river was doing before.
Which is pretty great, I think.
So you can write wind manager in high-level garbage-like languages without destroying composer latency.
The composer is not waiting on the wind manager to reply every frame.
And so, can winding composers are very latency sensitive programs.
You really don't have a very much time, especially with a high refresh rate monitor to render frames.
Especially if you're delaying your rendering to just make it just in time before the frame deadline.
To maximize or to minimize latency, you really cannot have a garbage collector in your compositor.
It's not going to work out well.
But it's nice to use a garbage collector when you're writing high-level wind management logic.
It's nice to use languages like hastal to specify things in a crazy, functional, high-level way.
And this wind management protocol makes that possible.
It's also just a much better development experience because you don't need to restart your compositor
and lose your whole wail insertion if your wind manager crashes.
Or if you just want to switch to a different wind manager or restart your own wind manager
because you change something that you want to try it out.
Such a much better development experience.
And I just want to promote ecosystem diversity.
I think it's really cool because as many wind managers as we had X wind managers,
there's still a massive discrepancy there because it was much easier to write an X wind manager
than it is to wait a whole wavelength composer as a play server.
And we still have a lot of catching up to do there.
And so that's my long-term goals.
Just going to have a more diverse ecosystem.
And help everyone to write their own wind manager if they want to.
And help build better wind managers on the island.
And not just wind managers really because this protocol should work just as built for discipline
environments really.
It's just a low level abstraction that makes it easier to write wail and software.
And so I hope to see some larger, more ambitious system environment products
should be willing to talk about this protocol.
There are some limitations.
This protocols are tricky to like normal 2D desktop stuff.
It's not going to make work very well for VR.
All coordinates are just 2D coordinates and a flat scene graph.
And so if you're using a VR composer, it's not going to help you really.
If you want wobbly windows, it's not going to help you currently.
I mean, maybe we can figure out some way of doing nice animations and crazy stuff like way
fire down the line.
But right now, you're probably going to have different problems with positive.
So it would be cool where the fire would implement this protocol.
Because then you can have both the best of both worlds.
I'm just not interested in working on wobbly windows myself.
That's not my approach.
Some projects like no more KDE probably want to own their entire development stack.
They've got maximal control, maximal integration between their processes there.
And so if you want to do that, maybe this is not for you.
But not every, not every solar developer has got a time to write an entire
compositor and display server as well as a window manager.
And so I'm usually good option for anyone like that.
And well, is there, this is increased global complexity?
I don't think it does.
There's a new asynchronous round trip involved, which was not there before in river.
But I think, making the specifying thing the state machine clearly has actually made
my clean code cleaner in both the compositor and the window manager.
It's a clearer separation of concerns.
And it's really kind of reduced the bugs I have in both cases.
Because there's less mixing of winter management states and winter management policy inside
the compositor is running the loop.
And trying to do synchronization between clients at the same time is also implementing
winter management logic.
Doesn't work out very well.
So separating out the client synchronization issues and the winter management policy
issues has really made my code a lot better.
Yeah.
So currently, this is the current staffs of the protocol.
It's implemented.
It's been stable for about a month and a half.
I'll be doing, I mean, I've been working on for like two years off and on.
There's a design of this protocol.
I went through several iterations already.
But I'm now confident enough that I'm very easy to clear a stable and we'll not
going to break your winter managers.
Just like links is not break user space.
You're free with not break winter managers.
So if you'll come to full depending on this and writing a winter manager against this
protocol, there's already at least nine winter managers I know of.
There's a list on our work if you like.
That I've been written against this protocol in the last one and a half.
So I think that's pretty crazy to see how many people are using this already.
I'm really excited to see that growth.
And there's lots of cool ideas being tried out.
I mean, it's still very early.
Early days of getting money and they're not very polished yet.
But it's a lot of cool ideas.
I mean, I'll show you some in a minute.
So don't worry.
And we're going to be having a river out of four or at least pretty soon.
My main two dudes left before the release are just writing better documentation.
The protocol itself is already very well specified.
The protocol has is basically just documentation.
But this is documentation aimed at people already familiar with writing
wayland clients and wayland compositors, perhaps.
So it's kind of, it's written like a wayland protocol.
And so it assumes you know about wayland and you know how to write a wayland client
and kind of how these things work already.
And I think if you already know those things, it's a very easy protocol to read
and pretty well specified and clearly specified.
However, we're missing like tutorials for people who are never written anything
wayland related before or maybe only familiar with writing an ex-window manager.
I'd like to have some nice documentation to get these people up to speed before we do
release.
And also maybe have like a documentation viewer that's nice and then reading ex-melfiles
because that kind of sucks.
So I'm going to work on those things and maybe type some new, like last minute
piece of requests.
There's not actually like any bugs reported right now.
I don't think.
Well, there's one thing and you fix that kind of requires to,
to be able to roots work though.
But really it's quite stable already.
The architecture has really proved itself.
And I've learned a lot about writing wayland compositors over the past five or six years.
So it's mostly just documentation in a bit of small features, like loose ends
and tie up before we do it release.
All right.
Here are a links to everything.
You can find me at these website in Macedon.
And their source code is on codeburg, of course.
Codeburg is a great project.
Everyone can get away from your GitHub, use codeburg, or something else open source.
They're not used GitHub.
We've got an IRC channel.
This is the most active worker communications that's sequence right now.
I also made a Zulip recently because I thought maybe not everyone likes
the IRC.
Maybe this is going to help us find a grow faster and get more user users.
But still, IRC is used a lot more than Zulip still.
So it's used a bit dead right now.
But if you don't like IRC and you want to use Zulip, come join us on Zulip and make that thing.
But right now, this IRC is pretty much the way to ask questions about river.
All right.
So demo time.
Let's see if we can like test out some winter managers.
There we go.
So let's see how this works.
Kind of hard to read in the screen.
Here we go.
All right.
So this is a winter manager called KWM.
You can see it's got like a whole SaaS bar at the top.
It's kind of VWM lake.
I forgot my keybiting so it seems.
Yeah.
So, yeah, demos.
I really didn't have any of your focus.
Well, so we can do this differently though.
I'm going to get this out of the screen where I can see what I'm doing.
Yeah, I should probably should have used that.
That would have been smart.
But here we go.
Now we've got KWM with Windows Open.
Now we can just find my mouse.
We can make this full screen.
We can see it even better.
That was it.
Well, luckily, I've got plenty of time.
Girl, I've got five minutes.
Well, ask questions.
Or think of your questions.
Okay.
What the heck is that?
I don't know what you said.
Only one minute manager can run at the same time.
I can't repeat the question.
Of course, that's for God.
The question is, what happens if one of the winter manager runs at once?
Well, that can't happen.
Because if a winter manager is already running,
the composable rejects the next winter manager that tries to start and just stop it.
So, you can't have that.
Another question.
Oh, yeah.
Can the winter manager install, like, traditional, with a service sign?
Yes.
The winter manager can draw a service side decoration.
That's correct.
Question.
How do you deal with, um, uncorporative clients who set in your,
in your state machine, your, if before you commit to use that?
Yes.
You're waiting for the clients to,
Yes.
That's right.
But some clients may do that immediately.
And some might be very slow.
The question is, how you deal with clients.
There are slow to respond with the right dimensions.
The answer is the very short time out in this.
The reason for waiting them is just for making the frame is perfect.
Perfect.
And so I think I've got a hundred milliseconds time on that right now.
Maybe it's 50 milliseconds.
I could maybe make it even less.
But, basically, the client responds to slowly.
That client will just get rendered.
Um, well, it just, you'll just have a frame that's not perfect,
because the client's not been fast enough.
And so that's thing about frame perfection requires all the clients
in the winter manager to be willing to well.
And so clients should respond faster than 100 milliseconds, of course.
But some of them don't.
And then you see one imperfect frame, which is not a very big deal.
Question.
Are you aware of any other composable,
that plans to implement the protocol?
I'm not aware of any other composable that plans to implement the protocol yet.
Um, but maybe someday.
I mean, right now it's kind of my job to make,
demonstrate the protocol's worth implementing and to get collaboration there.
Um, yes.
Question.
Yes.
Is there a portfolio behind the window?
For abandoned windows.
What will we find in this?
Repairing windows.
What do you mean by repairing windows?
That's an excellent time I believe.
So basically, like the control looks,
the dimensions that already get us to the window manager.
And the window manager basically.
So the window manager always has control of dimensions.
And position of the windows.
Is that answer the question?
Yeah.
Okay.
Any other questions?
Questions?
Yeah.
Do you have any plans of pushing that to the regular rules or something like that?
Um,
W roots is a lower level library.
I think it makes sense to have this implemented and the
compositor.
The question is if I have plans to push the window management protocol into
rubble roots and implement it there, rather than the compositor.
Um, not the time.
I want to keep control of it myself, so I can iterate quickly and kind of
not wait on anybody else.
Um, yes.
Um, for a compositor to have like, uh,
dynamic movement for example,
you have this overview.
Mm-hmm.
Would this kind of interaction where you have to ask the window manager for
the position you work well for the automations like that?
Um, so the question is about animations and if the program call supports like
more food animations.
Um, so this is kind of a question.
So I'm presenting it for like moving around a window with your mouse is kind of a similar thing.
That already works perfectly well.
Recycling windows interactively works perfectly well.
You can even resize many windows at once, even that they have window manager
random decorations.
That works for in a frame perfect fashion.
So that works pretty well.
Um, not many people have experienced animations yet though.
So there's still a bit of like new ground to be discovered there.
That's where you want to test.
I'm definitely happy to add new features to the protocol to support these use cases.
Um, question.
Yes.
Do you plan to ensure this more, um, use rate of the DWM that's intertile?
Um, that's for the window manager's this side.
Um, the window manager I showed you briefly K to UM has the questions about if I want to
introduce more different tiling algorithms.
And the answer is that that's probably what this program makes possible.
It makes possible to anyone to write any tiling algorithms as they want.
And so I think the one I showed briefly K to UM has got, um, a great algorithm,
like a side-scrolling algorithm, a master stack, a thing of yellow.
It's got everything W don't give you the WM it has for sure.
And the back question?
The question is if I would submit this protocol to the XT namespace.
Um, yes, I'd consider it, but I think there's some work we've done still to
make the this true design is really addresses more than just my compositors needs.
And that would require, by and from other compositors, um, behind you and
break in the back.
Sorry, if you're in an eighth question, so if you said a garbage collection is on
what's the sole problem for us?
Yes.
I guess it was very dynamic.
You would potentially see I picked up the code.
Um, so I, I, I'm using a, to the question is, can you, can you, can you
wait, it wouldn't matter if it's so slow that it makes you just your
proper environment unusable?
I'm sure you can, but I haven't seen it done yet.
The one I'm using for my daily driving is written in a very slow way.
It's written in a very slow, high level language.
And I've not done any optimization at all.
It's written in the simplest way possible, which is a lot,
repeats a lot of work every time it's a request.
And, exactly, yes, we only send requests to wind a manager when it needs to
make a decision.
There's no writing for every, every, every frame or every input events.
There's not added latency when I'm just typing into my terminal.
Um, yes.
Yes.
You said you only send an event to the wind a manager when something happened.
But the wind a manager is in trigger.
Move wind or whenever it wants to do anything.
Yes.
The wind a manager can submit a, a managed, the, the, the question is,
if the wind a manager can trigger, um, events on its owner core.
For example, if it gets a message over debust or someone clicks on the
stats bar.
The answer is the wind a manager can send a managed dirty request to the
compositor.
It'll tell it to start a new managed sequence next time it's idle.
Um, yes.
Question.
What sense of the way of like lovely windows and animations?
Uh, what stands in the way of that?
Um, the question is what stands in the way, okay, my time's up.
Sorry, everybody.
I'll answer all the rest of your questions in the hallway.
Thank you very much.
Come to my talk.
Thank you.