Emacs should become a Wayland compositor

Michael Bauer (IRC: permcu, [email protected])

The following image shows where the talk is in the schedule for Sat 2022-12-03. Solid lines show talks with Q&A via BigBlueButton. Dashed lines show talks with Q&A via IRC or Etherpad.

Format: 10-min talk followed by live Q&A (done)
Etherpad: https://pad.emacsconf.org/2022-wayland
Discuss on IRC: #emacsconf-dev
Status: Q&A finished, IRC and pad will be archived on this page

Description

Since Emacs learned wayland last year, it can now become a wayland compositor. Emacs is already a great window manager. Let us embrace this in the wayland future, where managers become compositors.

In this short talk I would like to convince you that this is a good idea and get you exciting about the possibilities. I then outline how to go about implementing this idea.

Afterwards I would very much like to get a discussion started together.

Transcript

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.

Questions or comments? Please e-mail [email protected]