herbstluftwm
herbstluftwm copied to clipboard
herbstluftwm
Wayland support
Is there any chance of Wayland support in the future? X is old, and supposedly slow, and it has some issues on newer systems. Wayland is supposed to fix the issues X has and is made for the current era. It'll also fix the tearing issues X has out-of-the-box. You could look at how Sway does it for examples.
Me personally I am interested in Wayland support. Thorsten, the main developer is less interested. The interest in the general hlwm userbase is pretty low.
In any case, supporting Wayland would only happen after the winterbreeze branch gets stable. The reason is that hlwm is very much tied into X and winterbreeze is generally helping with abstraction and code module separation.
Note that also the options for a Wayland backend still needs to mature. For example, with Weston it was so far only feasible to write a new "shell". Very recently, also libweston was released. I also find the wlc project (used by Sway) very intriguing. But there is still a lot of work to do.
Maybe winterbreeze will get ready "in time" ;) I am pretty sure the project would be open to this feature if anybody does the work, and I might even do the work myself, it would be a lot of fun. However right now I am not doing anything, so...
I am pretty sure the project would be open to this feature if anybody does the work, and I might even do the work myself, it would be a lot of fun. However right now I am not doing anything, so...
If the main developer isn't super interested, from the way you describe, that seems like it just means they aren't wanting to put in the effort themself. I can't imagine they would reject your work if you took it on!
Just as a proxy for the user base demonstrating its level of interest, I searched, "herbstluftwm wayland" and ended up here. That said I'm mostly worried about future proofing rather than some exciting feature of wayland.
Guys, any news on Wayland? Xorg is slowly dying and has some bugs which will never be solved. So what about Wayland in 2018/2019?
I am closely watching the ongoing developments regarding wayland window managers & compositors.
Currently, the wlroots project is making a lot of progress. It is promising as a foundation for hlwm given its history (coming from another tiling wm -- the one I mentiond in my comment two years ago).
I think it is a good idea to wait until wlroots is a bit more mature (swaywm is currently publishing the first alphas that are based on wlroots) and then have another look at it.
That said, hlwm is itself not ready for such an endeavor yet. You need to wait for a release with the new internal software architecture first.
Thanks ypnos for the thoughtful & informative response. I've been eyeing Wayland with mixed feelings for years. X's shortcomings are widely talked about and apparently significant but I worry that so much of the excellent work (much of it niche, but still very valuable to those who use it) done with X has to be re-implemented for Wayland (at significant cost of time & effort) and that much of it ultimately won't make the leap. Core progress means significant real-world regressions as folks spend valuable energy just getting back to the point where we can use the new tool to do what we were already doing with the deprecated one.
wlroots is an important project (obviously) helping to hedge against that by easing the burden of that re-development. I hope herbstluftwm and the highly efficient workflows that it can support will find capable expression on Wayland (assuming Wayland really is the future). If my amateur code tinkering ever evolves to the point that I could be of any real use to such projects I'll certainly try to be part of the solutions. Until then I'll be sending some $'s Mr. DeVault's way (unless someone knows of a better way of supporting wlroots) and keeping an eye on hlwm's progress.
Thanks again for helping me understand a little bit more about what's going on!
I believe that you raise some very valid and important concerns in your comment. Truth is that we need to embrace new technologies (on a healthy level) and projects like wlroots are very important to us, because otherwise we will be prone to just getting marginalized. I see new regressions in the use of Hlwm with desktop software on a regular basis now; first it was single applications like LibreOffice or Java-based GUI frameworks, now I also see GTK+3 becoming less and less usable at an alarming rate.
If there will be only GNOME on Wayland, basically only the GNOME way of desktop will survive in the GNU/Linux desktop world. You see this, e.g., in the discussion around client-side decorations (CSD). CSD basically plain sucks for any alternative window manager. However GNOME people love it and are pushing hard for it. We are at the verge of losing the ability of server-side decorations with Wayland altogether. Not because there are inherent technical reasons, but just because GNOME is currently establishing a status quo (for reference, see the discussion in January between Gnome, KDE, Sway).
So this is just one example on how we should take part in shaping what is coming up, whenever we have the capacity to contribute.
It looks at least like the wayland rewrite of bspwm is in progress: https://github.com/baskerville/bspwm/issues/199#issuecomment-668360173
Hi, If anyone want to know something about wlroots feel free to ask me, there is also new website https://wayland.app/protocols/ (not official) which wraps all wayland core protocols and wlroots as good and really deep documentation on how to use them which is apparently easier than reading code of other people or digging through XML files to get what you want :)
Hi, wayland-support is really one of the most-asked questions in recent years, so maybe I should comment on my plans here. In principle, I'm hoping that hlwm supports both (Wayland and X11) at some point. Right now, I'm working towards Wayland support in the sense that I'm trying to separate hlwm's core functionality and concepts from the communication with X11. It's simply not feasible to re-write hlwm for Wayland suppport or to maintain two code-bases, but I'm optimistic that by modularizing (and cleaning up) hlwm, it is at some point possible to just "add" Wayland support.
Hmmm... one of the biggest problems is that on X11, hlwm exists as just window manager connected to Display Server, on Wayland there is no "Window Manager", there is only your own Display Server where you should write and connect Compositor to this server which also manage windows as rectangles on screen. In order to implement tiling and control through herbstclient you need to write and implement own protocols. Next big problem is input and output handling, where you need own input handler managed by compositor where user can select keyboard layout etc. also it will manage your monitors in style of xrandr. I see that a lot of people ask about wayland support in other WM's Github issues as well but then no one of them actually know or understand how much work it need to be complete and functional.
Now lets talk about protocols a bit more. In this case hlwm would provide own protocols for tiling. status (for tags, windows state etc.) and for control of decorations and other things. Now for example user can choose own lang with wayland-scanner which allow him to create own IPC and connect it to server and use instead of herbstclient and e.g add own functions, tiling protocol will allow users to create own layouts, new functions or change frames to dynamic tiling and tile windows without them. Status protocol would be used for bars and similiar things for displaying tags, their state, focused window name or windows to minimize/maximize etc.
I am continuously following the current development reg. Wayland and available frameworks. From my point-of-view it would, at the current moment, be a pretty obvious choice to base any hlwm wayland port on wlroots.
I would hope that the intrinsics of compositing, rendering, input handling would be done by wlroots and we would only need to tap into the according places to control window coordinates and size, render our simple frames, process keyboard and mouse events we are interested in, obtain monitor coordinates. For example, I would assume that wlroots comes with support for "wlr output management" protocol and any xrandr-alike clients can talk this protocol with us without much work from our side (we would only need wlroots to expose the functionality and ensure we get to know about any changes). Is that a good or bad assumption?
Regarding our own IPC protocol I wonder if we would need to translate it to XML protocols or could stick with what we have (basically being compatible with Xorg hlwm on a protocol level)? Having the IPC protocol at a level where one can directly talk to hlwm easily, e.g. in a Python script, was in discussion several times for a long time. The question is what is the right way to get there, jump on the Wayland protocol train but also offer the same interface on old hlwm? Or write a specification/bindings around the current protocol?
Offering IPC protocols for a Wayland-based hlwm / hlwm clone that is not also supported by old hlwm would result in wayland-exclusive user scripts.
I think it all depends on how easy to use wlroots is. But I'm optimistic.
Regarding the IPC, I'd hope that there is a wayland-method such that herbstclient can automatically use this (instead of the X11 way) when running within a wayland session. Any language binding then can invoke herbstclient (the python bindings do this), but of course one could also create a libherbstclient (I simply didn't have a need for it, thus there is no library built by hlwm's build system)
I would hope that the intrinsics of compositing, rendering, input handling would be done by wlroots and we would only need to tap into the according places to control window coordinates and size, render our simple frames, process keyboard and mouse events we are interested in, obtain monitor coordinates. For example, I would assume that wlroots comes with support for "wlr output management" protocol and any xrandr-alike clients can talk this protocol with us without much work from our side (we would only need wlroots to expose the functionality and ensure we get to know about any changes). Is that a good or bad assumption?
As far as I understand, wlroots makes this plug-&-play, but (as of now) with a lot of cables to be plugged. (But I observe from distance, so the situation may be different.)
Regarding our own IPC protocol I wonder if we would need to translate it to XML protocols or could stick with what we have (basically being compatible with Xorg hlwm on a protocol level)? Having the IPC protocol at a level where one can directly talk to hlwm easily, e.g. in a Python script, was in discussion several times for a long time. The question is what is the right way to get there, jump on the Wayland protocol train but also offer the same interface on old hlwm? Or write a specification/bindings around the current protocol?
AFAIK anything not dependent on Xorg should work (but if I’m not mistaken, hc uses X to access the socket?). Sway does it with a separate socket & an environment variable: (sway-ipc.7)
The IPC protocol uses a UNIX socket as the method of communication. The path to the socket is stored in the environment variable SWAYSOCK and, for backwards compatibility with i3, I3SOCK. You can also retrieve the socket path by calling sway --get-socketpath.
Also, extending the Wayland protocol could cause problems (depending on how well it checks if a feature is or isn’t supported by the server or client).
IPC is pretty simple, you need to create e.g. 2 protocols for status (tags/window/frame state etc.) and options like spliting frames, changing attributes etc. to do that both must have implemented both protocols, hlwm as compositor and ipc to talk directly to compositor/server through your display server socket. Speaking about custom protocols, when you provide them as public then people can use whatever language they want create own config file by passing events directly into server, user will just need acces to those protocols and wayland-scanner to generate e.g. C/C++ headers for it then make library as configuration instead of standard IPC provided by hlwm.
Wlroots itself isn't that easy as people think, to gett fully functional compositor with popular protocols standarized by wlroots you need minimum 5k loc or more, depends what you actually want to implement.
I'm working with wlroots right now and it's really low level, it's not just another library but "framework" or "wrapper" around pure libwayland (Wayland implementation in C), there is few libs for writting compositors, you are not only limited to wlroots in C/C++/Zig but there is Smithay (rust) and wayland-rs (wayland implementation in rust) but problem with rust is it's own safety which is hard to implement e.g. when you unplug monitor your compositor need to process that it's unplugged, in Rust it's like spamming events to do that or using unsafe code.
As example I can use my RoseQuartz which is written in Zig (code here). Took me over year to learn about Wlroots and Wayland to finally write first open source Compositor and I'm still not happy because it's really hard and complicated where you call directly to GPU through OpenGL/Vulkan (vulkan renderer isn't merged into wlroots yet) and directly to libinput through pasring output into libxkbcommon. However final effects is really nice and performance boost is huge compared to X11. Here I'm leaving example vid, 600+ loc to get server, compositor, keyboard and mouse management in really basic level (keybindings like delete to kill compositor and left arrow to change current view) https://imgur.com/a/dU0tQtQ
Also, extending the Wayland protocol could cause problems (depending on how well it checks if a feature is or isn’t supported by the server or client)
To correct myself: there should be no problems, as actually a (too big) part of Wayland is approximately like this: new protocols, supported only by some compositors.
I realised that what I said was wrong when I today saw that kiwmi does it this way.
Still, the fact that using the Wayland socket for wm-specific client is possible, doesn’t mean it is the only possible/correct way, & for hlwm it even makes more sense that the client stays (almost) the same.
the client stays (almost) the same
Uhm, sorry for bumping this with a silly comment again, but…
I really didn’t expect the client to be so tightly bound to Xorg (& I should have read more of its code before making any comments here). The ‘almost’ then only applies to the messages, but not the way they are exchanged with hlwm; however, that could theoretically be the case even if hlwm made a custom Wayland protocol (but then the problem is the Wayland socket is only available on Wayland, anyway).
Maybe I shouldn’t even have written this, and I imagine there’s something completely wrong again.
I'm sure you've probably already encountered these, but if not, it might be worth reviewing the experiences of others who have started down the road of building a wayland compositor in Rust:
- https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html
- https://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html
Anyhow, this is perhaps getting off topic, as this issue is about wayland itself and not necessarily the choice of implementation language
Hey, I am planning to try out HLWM soon, where can I track the progress of the Wayland transition?
Hey, I am planning to try out HLWM soon, where can I track the progress of the Wayland transition?
You can keep asking on IRC every minute or so, @t-wissmann already knows this from me 😀. Jokes aside, i wouldn’t hold my breath (yet). You can try hlwm as is and you’ll see if you want something on wayland more than this wm.
Before reading this, keep in mind that Wayland existed for over 14 years by this point. X gained adoption by commercial companies on different Unix (not GNU/Linux, BSD's and Mac we have now) distributions after ~2 years of development.
As an outside observer, years using and reading about different X11 window managers, Wayland compositors and desktop environments, all of the information I collected about Wayland points to one conclusion: it's a very difficult to use, barebones display server and protocol. The main reason is, unlike X, Wayland is policy over mechanism. What I mean by this is, they really try hard to talk about protocols for every usecase instead of coding a specific mechanism for doing it. This is why nobody really did clipboard right before wl-clipboard came along and finally became the de-facto implementation for most compositors. This is why nobody did any screen sharing before pipewire provided a mechanism for doing that. This is why every feature missing in the standard is implemented in GTK, Qt, dbus, Pipewire, systemd or other external IPC systems. This is why everybody has such trouble making good full-featured Wayland compositors - you need a team of competent programmers who know the internals of XML-riddled specifics with ugly interfaces, an uncomfortable amount of Linux-specific assumptions, and use-after-frees. What I'm really looking forward to, however, is the Arcan project. The author, software (reverse-)engineer, seems to understand the desktop problems much deeper than I do, and coded quite a few mechanisms to migrate from X-specific assumptions over the span of ~15 years: the Arcan display server itself, the SHMIF (Shared Memory InterFace) IPC system for everything desktop, A12 (the X12 we deserve), and a few desktop environments to show what is already possible with it: Durden (traditional desktop), Pipeworld (Zooming UI), Safespaces (3D & VR). I settle on herbstluftwm for a while, and I don't want this project to die with X, but I also don't want it to force systemd down my throat with seatd/elogind (every Wayland compositor I know requires these), so please, if you are really going to do anything to migrate from X, at least give SHMIF a try. arcan-Qemu, Xarcan, and arcan-wayland are examples of interfaces that are possible with it. It's possible to use without the rest of Arcan, in theory. In practice, you probably need to compile it separately and provide a couple of stubs, or compile Arcan-SDL and use that. Ask letoram for specifics.
I don't think that you fully understand how elogind or seatd works. First of all they don't relly on systemd in any way, they were created as cross-platform init independent session management interfaces which allows you to run display server safely in userspace without the root access.
It's already widely adopted by VFX studios which moved from X11 on IRIX to Wayland on Linux few years ago, as the preferred display protocol used on workstations for their artists.
Arcan is still just experimental concept without real userbase and tooling. Major graphics APIs are having built-in integration with both X11 and Wayland, same for graphics drivers for hardware accelerated apps. You also cannot simply implement HDR or VRR without Wayland. For example HDR requires high-perfoemance low level renderer written using Vulkan.
Many companies including Red Hat and System76 are investing time and money into more standarization of streamlined features from macOS and Windows, just like mentioned HDR to make linux become first-class choice for high performance enterprise workstations used not only by developers but now also artists and people who don't know or don't want to know linux internals.