exwm
exwm copied to clipboard
ch11ng
[question] Issue with elisp and wayland compositor implementation
In the wiki page it is mentioned that it's not possible to implement a wayland compositor in pure elisp. I was wondering what exactly is the limitation? Also isn't it maybe possible to use Emacs dynamic modules to make something in another language on top of wlroots and use it in elisp?
In the wiki page it is mentioned that it's not possible to implement a wayland compositor in pure elisp. I was wondering what exactly is the limitation?
With 'pure Elisp' I mean no FFI. Most Wayland compositors call low-level interfaces to manipulate graphics, but we can not implement such a compositor since those interfaces are largely absent in Elisp and the performance would be of a great concern. So I tend to make a subcompositor that runs on top of another compositor (mutter for example) to offloads most dirty work and only deals with window management. But even this simplified design can not be realized due to the inability of Elisp to send/receive file descriptors through a socket.
Basically FDs are used to share memory between compositor and client in the Wayland protocol. For instance, a wl_buffer represents a piece of memory containing the content of a window filled by a client, and the compositor can access it with the FD passed by the client. With a subcompositor it should be able to relay FDs between clients and the real compositor at least (though I'm not sure if it's sufficient for it to work).
However the only way to pass an FD is to put it in the control messages of a socket (which is not part of the payload), but in Elisp this is not possible at least for now. There was a patch proposed by someone on the emacs-devel list to implement this but was never accepted.
Also isn't it maybe possible to use Emacs dynamic modules to make something in another language on top of wlroots and use it in elisp?
Of course this is possible. But loading dynamic module is generally disabled in distributed binaries so only a few users can actually benefit from such work. I prefer a pure Elisp way.
The performance using shared memory for graphics wouldn't be amazing, but it would probably be Good Enough™. Maybe you could nag emacs upstream to try and get that fd passing script in?
I agree that without a convenient means of loading dynamic libraries, leveraging wlroots would be difficult/near-impossible. However, solving this problem would save you a ton of work in making a mature, polished Wayland compositor within emacs by leveraging wlroots.
Oh, and solving this fd problem might make it possible to write a pure-elisp Wayland backend for emacs (i.e. running emacs in a Wayland window), which could make the change more appealing to upstream.
In the wiki page it is mentioned that it's not possible to implement a wayland compositor in pure elisp. I was wondering what exactly is the limitation?
With 'pure Elisp' I mean no FFI. Most Wayland compositors call low-level interfaces to manipulate graphics, but we can not implement such a compositor since those interfaces are largely absent in Elisp and the performance would be of a great concern. So I tend to make a subcompositor that runs on top of another compositor (mutter for example) to offloads most dirty work and only deals with window management. But even this simplified design can not be realized due to the inability of Elisp to send/receive file descriptors through a socket.
Basically FDs are used to share memory between compositor and client in the Wayland protocol. For instance, a
wl_bufferrepresents a piece of memory containing the content of a window filled by a client, and the compositor can access it with the FD passed by the client. With a subcompositor it should be able to relay FDs between clients and the real compositor at least (though I'm not sure if it's sufficient for it to work).However the only way to pass an FD is to put it in the control messages of a socket (which is not part of the payload), but in Elisp this is not possible at least for now. There was a patch proposed by someone on the emacs-devel list to implement this but was never accepted.
Also isn't it maybe possible to use Emacs dynamic modules to make something in another language on top of wlroots and use it in elisp?
Of course this is possible. But loading dynamic module is generally disabled in distributed binaries so only a few users can actually benefit from such work. I prefer a pure Elisp way.
Thanks a lot for the thorough explanation. I really appreciate it :+1:
Oh, and solving this fd problem might make it possible to write a pure-elisp Wayland backend for emacs (i.e. running emacs in a Wayland window), which could make the change more appealing to upstream.
I'm not sure if this is essential but Emacs's platform-specific UI code is mostly in C and already has access to file descriptors. Elisp is (ideally) agnostic of the underlying UI so it probably won't deal with the Wayland protocol directly.
@ch11ng would you mind linking to the patch on devel that you mentioned so that I can try to understand this issue better?
I'd also love to see this become a reality.
Maybe this is useful for someone: https://github.com/masm11/emacs
A pure gtk emacs port such as the one @masm11 is working on will certainly be necessary to first get emacs running under wayland. Once that is possible it seems @ch11ng is indicating that porting exwm won't be very easy which I certainly believe given that I'm not aware of a single tiling wm that was actually ported from x11 to wayland. It seems that most wm projects were forced to start from scratch in order to move to wayland.
Using dynamic modules was mentioned previously as a candidate for an exwm wayland port and I think it may be worth revisiting that idea given that emacs 27 will turn on dynamic module support by default and so by the time users are on a pure gtk emacs, we can probably assume module support is there. Using modules would likely allow more flexibility in having performance critical code reside in c and reduce overall complexity as opposed to some emacs-lisp bindings to wlroots (or whatever other wayland compositor library is chosen although it looks like wlroots does have common lisp bindings)
@minikN @akirakyle That looks promising. Thanks for the info! X11 and Wayland protocols are totally different so nearly nothing can be shared. With dynamic modules enabled by default it's of course preferable to reuse their standard libraries. Glad to see the community made that change.
@ch11ng masm11's pgtk branch is now a branch of the official emacs repo: https://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/pgtk.
https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg01141.html
Last fall I had actually started to work on a wlroots based emacs module as a wayland window manager controllable from emacs. What I ended up with was actually emacs-webkit. In principle the same event handling that emacs-webkit uses could be used to make a wlroots emacs module semi-efficiently and bidirectionally communicate with emacs. Personally, I've managed to move myself almost completely inside emacs so minimally using sway just to run pgtk emacs is sufficient for me.
Last fall I had actually started to work on a wlroots based emacs module as a wayland window manager controllable from emacs. What I ended up with was actually emacs-webkit. In principle the same event handling that emacs-webkit uses could be used to make a wlroots emacs module semi-efficiently and bidirectionally communicate with emacs. Personally, I've managed to move myself almost completely inside emacs so minimally using sway just to run pgtk emacs is sufficient for me.
How do you run applications other than a browser if not using sway? I'll take a look at emacs-webkit, looks super interesting!
How do you run applications other than a browser if not using sway?
I'm not quite sure I understand the question. Since the only two apps I really use are emacs and a browser, by using emacs-webkit, I can run a browser inside emacs and never really have to leave.
How do you run applications other than a browser if not using sway?
I'm not quite sure I understand the question. Since the only two apps I really use are emacs and a browser, by using emacs-webkit, I can run a browser inside emacs and never really have to leave.
Yeah I got that. I just thought you had to use some (GUI) applications other than emacs and a browser from time to time and wondered how you'd open them. But alright I got it now 👍
Yeah I got that. I just thought you had to use some (GUI) applications other than emacs and a browser from time to time and wondered how you'd open them. But alright I got it now 👍
Oh yeah in those instances, sway manages them. There isn't much friction there because my needs for switching apps is so limited that the tabbed layout suffices for me in such cases. It still might be fun to write a wlroots dynamic module just to be able to get rid of sway. If no one gets around to it before me, I might do it someday, but I've been very busy with other things lately.
stumpwm has a wayland port, with a custom compositor "heart" written in C, geared towards supporting the CL code, but apparently not CL - specific: https://github.com/stumpwm/mahogany/tree/master/heart
Maybe that could be re-used for exwm?
vterm has a C++ module that it builds with cmake on first run, so that approach works / is proven
I was working on a PoC project using wayfire with IPC plugin. After that, I noticed that using wlr-foreign-toplevel-management would be better, but I had no time to work on it recently.
