Hello EmacsConf and hello fellow Emacs fans.
My name is Michael Bauer, and I'm from Germany.
I'm gonna talk to you about "Why and how Emacs
should become a Wayland compositor."
And it already kinda is a Wayland compositor.
This talk is composed by Wayland and Emacs.
If I'm talking about a Wayland compositor
or Emacs as Wayland compositor,
I mean it in the sense that
EXWM is an X window manager. I hope you know EXWM.
So, why?
Emacs can do Wayland now, that was a stopper
before, and now it's solved with `pgtk` branch.
It makes the Emacs toolbox bigger,
which is always a good thing.
And the cool thing about Wayland, which is not
possible under X is, it can run standalone
on the Linux kernel interface, or nested under X,
or even nested under Wayland.
The compositor features of Emacs doesn't mean
it has to take over the whole output.
It can use them, even if it's just like
a normal window or normal program.
And last reason is,
I want to keep living inside Emacs
and Wayland is the future, apparently.
EXWM use case is the first use case.
You take a Wayland surface and put it inside
an Emacs window. You see it right below.
The video of me is a Wayland surface,
and it's inside an Emacs window managed by Emacs.
Emacs does the input, and the clipboard handling,
and can insert itself here, and do great things.
And it's a possibility to Lispify the Linux desktop,
as Emacs Lispifies the command line.
The other use case is the XWidget use case.
I don't know if you know XWidgets.
It's embedded X windows inside Emacs.
There's a web browser available in Emacs.
With Wayland, you could embed anything that can
create a Wayland surface like video, web, or 3D.
Think OpenGL, something like
EmacsGL would be possible.
And we wouldn't have just images like we have so far.
So, how to implement this Wayland compositor?
I'm going to tell you how I did it,
or I did this demo I'm showing you right now.
First of all, how does Wayland work?
Wayland is a protocol in XML.
It's a server and client, and they share a set of
objects, and the objects have methods.
They are specified in the protocol,
and Wayland also says how the server
and client talk to each other.
First blocker for Emacs becoming a Wayland
compositor is that Emacs and Wayland both have
their own event loop, and you can't merge them too.
But you don't have to merge them
because you can just make Emacs speak Wayland.
So, Emacs becomes a Wayland client,
and there's an extra server Emacs is talking to.
So, we need a minimal Wayland server that does all
the stuff Emacs can't do and do the rest in Emacs.
---The minimal Wayland server, I did it in wlroots.
That's the library behind Sway. I think it's
the Wayland library to do stuff like this.
I implemented four different things to make it work.
It's these three letter acronyms on the left.
It's Emacs, Wayland, and then it's a server,
a client, a protocol, and buffers.
The server is written in C and it's mostly tinywl.
It's the example of wlroots,
and it's around 1000 lines of code.
ewc, the Wayland client in Emacs,
is the thing I'm most proud of.
It's 300 lines of code, and it is a
fully featured Wayland client in Emacs.
With this, Emacs can speak Wayland,
and then I implemented Emacs Wayland protocol.
It more or less allows Emacs to become a Wayland
window manager, so it's not actually the compositor.
The compositor stays in C, but Emacs is
now a Wayland window manager!
And the last thing is Emacs Wayland buffers.
It's the window manager part.
It's around 500 lines of code,
and it does the buffer management inside
Emacs windows, or floating right like you see me
now floating on the right.
It works, but it is still buggy,
and it is also missing input handling,
so there's more code to come for this to work.
Some caveats about this approach.
wlroots is around 60 kilo LoCs (Line of Code)
and in active development.
They have like a slogan 60 kilo locs of code
you had to write anyway to make a Wayland
compositor. And no, you don't have to write it.
But I still remember when it was like 50 kilo locs,
and now it's 60. And it's like a moving target.
I think it could be quite a lot of work
to keep up with it.
Yeah, it could be quite a bit of work.
Some windows don't like to keep the aspect ratios.
You tell them and you have to crop them.
And the interface I use in wlroots for doing this,
`wlr_scene`, can't do cropping yet,
so this doesn't work.
Another problem is with GTK.
Once Wayland is enabled and it stays on.
This doesn't make sense.
Okay, if you kill the Wayland server,
GTK kills Emacs, that's not a good thing.
And it's still a bit of work and fussing needed
to get this to work reliably.
It's quite buggy right now.
And that brings me to my call to action.
I think making Emacs Wayland capable is
a further step to make an Emacs OS.
It gains output and input handling.
Output handling is already there,
input handling is still missing,
but Emacs can manage monitors, outputs,
different frames if it's like nested,
And inputs, keyboards, simulation keys,
stuff like that.
We could use it in more ways for Emacs display, maybe.
Wayland just manages simple pixel buffers,
so it's a protocol for managing pixel buffers.
And in a sense, we could go back to
the old X ways and maybe even ditch GTK.
I don't know, but why need it?
We can composite without it.
Let's make buffer menus, buffer world, buffer.
Emacs Wayland protocol, like I did it,
allows a very concise design, and it allows
to improve on the EXWM code base.
And I wrote KISS style because EXWM has
workspace management integrated.
I don't think that's needed, like Emacs does it.
Why do you have to do something extra?
So why do it?
To finish the call to action,
if this is the thing you want to see in Emacs,
maybe you want to get involved, have some ideas,
so we could discuss it.
I'm looking forward to discuss with you
and hear your questions and ideas.
I want to say a big thank you to the
organizers of EmacsConf and the other speakers
for making this event possible.
Thank you, and see you.