Emacs should become a Wayland compositor
Michael Bauer (IRC: permcu, perma-curious@posteo.de)
Talk
Q&A
Description
Help wanted: Q&A could be indexed with chapter markers
The Q&A session for this talk does not have chapter markers yet. Would you like to help? See help with chapter markers for more details. You can use the vidid="wayland-qanda" if adding the markers to this wiki page, or e-mail your chapter notes to emacsconf-submit@gnu.org.
(If you want to work on this and you think it might take you a while, you can reserve this task by editing the page and adding volunteer="your-name date" or by e-mailing emacsconf-submit@gnu.org.)
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.
Discussions:
Discussion
Notes
- Call to action - let Michael know if you know anyone else working on something like this so they can collaborate and not duplicate effort.
- Site (coming soon): perma-curious.eu
- I am an EXWM user and would be very happy to test your code! Looks great!
- I know of many people quitting EXWM because of the lack of active development. Your project could be a kind of revival!
- I would be interested to try it out. I'm on sway right now.
- What I mean is that people are moving to other WMs which work or are planned to work with Wayland
- sway.el might have something that could be used
- Feedback:
- Thank you very much for the talk and the work.
- Thank you for sharing your amazing work!
- Yes, thank you for the talk, looks really promising
- thank you for the talk
- Thanks and great job!
Questions and answers
- Q: Are you using it as a replacement of EXWM?
- A: No, not yet, but I'm planning to.
- Q:Is this testable?
- A:
- Q: Have you considered contributing it to emacs core?
- A:
- Q:Question: this is wayland compositor in Emacs? What different with
XReprarent in X11 ?
- A:No, I planned it, but no. Does not handle file descriptors. It's a compositor that talks to Emacs. etc. I don't know what XReparent is; have to skip that.
- Q:What does it mean for emacs to be "a wayland compositor"? What
can the end users do with it?
- A:
- Q: How would multiple monitors be handled? Separate Frames?
- A:
- Q: Could you make it so you can restart emacs without loging out;
or switch to non emacs buffers while emacs is blocking: these are
the biggest issues with EXWM? Maybe in the future with a different
ui for non emacs buffers.
- A:
- Q:Did this project can implement mirror of buffer for Emacs
different window?
- A:
- Q:How does the single-threaded affects the project?
- A:
- Q:this technology need write wayland server? Can it works with
Gnome3 ?
- A:
- Q: Could there be a emacs-wayland-server and just connect with
emacsclient?
- A:
- Q: When you share your code, could you provide the equivalent of an
.xsession script for those who are on EXWM and want to test?
- A:
- Q: there have a demo to show this emacs-wayland-compositor, even it
buggy now? Just curious.
- A:
- Q: So the current limitation is that buffer mirroring doesn't respect different widths/heights?
- A:(answered - transcript tbd)
- Q:Could you use some of this package with other walyand compositers
"probably not all of it" , sway, kde, river, gnome.
- A:(answered - transcript tbd)
- Q:Will Wayland support reach feature parity with EXWM in the future?
Will there be other tradeoffs?
- A:(answered - transcript tbd)
- Q: What is the biggest difference between Xorg and wayland that you
have found?
- A:(answered - transcript tbd)
- Q: Did you know EAF https://github.com/emacs-eaf/emacs-application-framework ?
- Q: Do you have the code available somewhere (git repo)?
- Q: So the current limitation is that buffer mirroring doesn't respect different widths/heights?
Other discussions from IRC:
- If I understand correctly, this project is more like philosophy of EXWM, but it not based on X11, instead based on Wayland.
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 perma-curious@posteo.de