River: A dynamic tiling Wayland compositor(github.com)
github.com
River: A dynamic tiling Wayland compositor
https://github.com/riverwm/river
41 comments
Wayland is a protocol - not an implementation. It tries to minify latency by merging together some of the components X11 had and tries to do this in a slim and faster way eliminating "design flaws".
The implementation of the protocol may differ, but I know for example MUTTER, that is used in GNOME (https://gitlab.gnome.org/GNOME/mutter)
This article has nice and not too complex visualisations and explanations: https://www.secjuice.com/wayland-vs-xorg/
The implementation of the protocol may differ, but I know for example MUTTER, that is used in GNOME (https://gitlab.gnome.org/GNOME/mutter)
This article has nice and not too complex visualisations and explanations: https://www.secjuice.com/wayland-vs-xorg/
> It tries to minify latency
Quiet the opposite. Tearfree rendering, forced vsync and the completely opaque way of interacting with graphics memory in order to fulfill the "every frame is perfect" philosophy means Wayland is optimized for all kinds of things (mainly to give involved consulting firms some lucrative gigs) but certainly not latency.
Quiet the opposite. Tearfree rendering, forced vsync and the completely opaque way of interacting with graphics memory in order to fulfill the "every frame is perfect" philosophy means Wayland is optimized for all kinds of things (mainly to give involved consulting firms some lucrative gigs) but certainly not latency.
It's more nuanced than that. If your goal is to have a desktop without screen tearing, you will beed a compositor. Wayland will do better at minifying latency than an X11 compositor due to having better frame scheduling. This is especially pronounced on very low-end ARM devices like the Pinebook that experience lag on DWM but are incredibly snappy under Sway.
If you are fine with visual glitches like screen tearing due to e.g. a lack of vsync then X might have less latency.
If you are fine with visual glitches like screen tearing due to e.g. a lack of vsync then X might have less latency.
> If you are fine with visual glitches
There are cases where tearing is extremely distracting, like playing videos or scrolling in the browser. There are cases where tearing will not be noticed at all but low latency might be beneficial, e.g. when you only have small areas of the screen that are updated, like moving the mouse cursor or editing text. And there are cases where it is a user preference, e.g. Games (Many people play competitive FPS Games without vsync whereas scrolling without vsync in strategy games will be very distracting).
The point is to give the user a choice when there is a trade-off. The trade-off here is vsync vs. low latency.
Wayland makes the choice for you. On X11 each application can do what makes sense for that particular use case and on top of that the compositor can be turned off, on or even be replaced at runtime without affecting running programs. X11 is superior technology in every way if you ask me.
There are cases where tearing is extremely distracting, like playing videos or scrolling in the browser. There are cases where tearing will not be noticed at all but low latency might be beneficial, e.g. when you only have small areas of the screen that are updated, like moving the mouse cursor or editing text. And there are cases where it is a user preference, e.g. Games (Many people play competitive FPS Games without vsync whereas scrolling without vsync in strategy games will be very distracting).
The point is to give the user a choice when there is a trade-off. The trade-off here is vsync vs. low latency.
Wayland makes the choice for you. On X11 each application can do what makes sense for that particular use case and on top of that the compositor can be turned off, on or even be replaced at runtime without affecting running programs. X11 is superior technology in every way if you ask me.
From a purely practical point of view, for me personally, I have a laptop where no matter what I tried, with X I got insane constant screen tearing. I tried with and without compositors, different configuration, different drivers. Nothing worked for me. I tried wayland and its been running silky smooth without any tearing whatsoever.
So, from a personal practical perspective, whatever Wayland does has worked for me, while X11's "superior technology" has completely failed me, on that laptop.
So, from a personal practical perspective, whatever Wayland does has worked for me, while X11's "superior technology" has completely failed me, on that laptop.
On a technical/conceptual level X11 can potentially be the best of both worlds and Wayland can't. In practice drivers and programs have bugs, sure. But that can not be blamed on X11 as protocol/API.
That’s like saying you can’t blame C for buffer overrun vulnerabilities because those are just bugs.
If the system makes it easy to write buggy programs and there are common problems that take a lot of effort for developers to overcome it is a bad system.
If the system makes it easy to write buggy programs and there are common problems that take a lot of effort for developers to overcome it is a bad system.
X11 has no GUI isolation which in this day and age is inexcusable in a desktop operating system. The only decent attempt at proper isolation for X that I know of is Qubes, done using Xen.
Furthermore, Wayland can have lower input latency than X if you are dealing with more complex input. Text nowadays has grapheme clustering, ligatures and text shaping (including runtime text shaping), and other oddities; this is a heavy task that can incur latency. Latency can be reduced by offloading some of this to the GPU. Frame timing combines well with this approach to ensure that only displayed frames get rendered, synced with display refresh. The result is dramatically lower latency when taking into account display refresh rate.
In other words, Wayland's vsync support can make complex tasks like modern text input incur lower latency and use fewer resources.
On Sway, for instance, if you tune the compositor with sway-input, you can actually achieve lower latency than on X11 WMs like dwm, even without a compositor. This is even more pronounced on low-end ARM machines.
Furthermore, Wayland can have lower input latency than X if you are dealing with more complex input. Text nowadays has grapheme clustering, ligatures and text shaping (including runtime text shaping), and other oddities; this is a heavy task that can incur latency. Latency can be reduced by offloading some of this to the GPU. Frame timing combines well with this approach to ensure that only displayed frames get rendered, synced with display refresh. The result is dramatically lower latency when taking into account display refresh rate.
In other words, Wayland's vsync support can make complex tasks like modern text input incur lower latency and use fewer resources.
On Sway, for instance, if you tune the compositor with sway-input, you can actually achieve lower latency than on X11 WMs like dwm, even without a compositor. This is even more pronounced on low-end ARM machines.
> GUI isolation
Just like vsync, GUI isolation is a trade-off. It comes at a cost with major inconveniences for the user and programmer. On a system running primarily trusted open source applications GUI isolation is not a priority whereas letting programs talk to each other without restrictions is. On a system where you primarily run proprietary software from untrusted sources (like Android or Windows) GUI isolation has a high priority.
> The result is dramatically lower latency
You understand that the bandwidth between your front buffer and monitor is many orders of magnitude lower than the bandwidth from GPU to front buffer? This means it is impossible to have lower latency if you force vsync (especially if you have unpredictable events like user input). Besides, all the weird "timing solutions" and "offloading to the GPU" you are proposing can be implemented on X11 as well. Wayland is just a protocol to manage multi process access to memory on your GPU. Inherently it doesn't do more than DRI3 on X11.
Just like vsync, GUI isolation is a trade-off. It comes at a cost with major inconveniences for the user and programmer. On a system running primarily trusted open source applications GUI isolation is not a priority whereas letting programs talk to each other without restrictions is. On a system where you primarily run proprietary software from untrusted sources (like Android or Windows) GUI isolation has a high priority.
> The result is dramatically lower latency
You understand that the bandwidth between your front buffer and monitor is many orders of magnitude lower than the bandwidth from GPU to front buffer? This means it is impossible to have lower latency if you force vsync (especially if you have unpredictable events like user input). Besides, all the weird "timing solutions" and "offloading to the GPU" you are proposing can be implemented on X11 as well. Wayland is just a protocol to manage multi process access to memory on your GPU. Inherently it doesn't do more than DRI3 on X11.
> On a system running primarily trusted open source applications
I'm not sure how releasing the source code to a program alters its security state or makes the bugs disappear. Security audits typically rely on binary analysis and runtime inspection rather than source code review, regardless of source model. This is because doing so takes into account things that can violate the contract that is source code: the larger runtime, toolchain bugs, and source code bugs that pass by flawed human eyes unnoticed. Assuming your binaries aren't obfuscated, binary analysis is one thing that is incredibly difficult to hide from. The whole field is actually moving towards stuff like black box fuzz testing; I can guarantee that you can thank that for some of the most significant security fixes you've benefited from in the past couple years.
FLOSS has many merits, but security is lower on that list every year. Proprietary software does not have a monopoly on vulnerabilities.
Also, there is no such thing as a "trusted program" unless you employ formal proofs; Project Everest is one example and their progress pales in comparison to less rigorous TLS implementations. Everyone writes buggy code, and some bugs are more exploitable than others.
Finally, most users do regularly run hostile programs in the form of remote JavaScript apps in runtimes that we call Web Browsers. Browsers use all the OS features they have access to in order to provide sandboxing. On Linux, this includes seccomp for syscall filtering, multi-process isolation, and user namespaces; however, this typically lacks robust GUI isolation on Linux and BSD due to the lack of support in X11. Chromium has a (very partial) mitigation by limiting access to the GPU process while Firefox does no such thing; Webkit2GTK browsers leave you even more exposed as they often disable sandboxing. If open source was perfectly secure, Firefox wouldn't regularly lead Pwn2Own's browser exploits.
This isn't limited to browsers: PDF readers, ebook readers, email clients, media players (ASS subtitles might as well be programs of their own), and countless other programs literally exist primarily to work with untrusted content.
> This means it is impossible to have lower latency if you force vsync (especially if you have unpredictable events like user input).
User input in 2022 is complex work that is far more involved than just printing characters one after the other. Characters interact with each other, modify each other with context, overlap, change each others' direction, and switch meanings. Libraries like harfbuzz are quite advanced. With all this work taking place, vsync does reduce latency by reducing the amount of rendering: vsync allows the rendering to skip changes that don't sync with a display refresh.
> Besides, all the weird "timing solutions" and "offloading to the GPU" you are proposing can be implemented on X11 as well.
Wayland has excellent support for frame timing; X11 just does not. You'd have to break compatibility or layer a more advanced compositor on top, and the latter won't be following any standards that programs can adopt. Wayland standardizes the process so that programs can actually reap the benefits. Terminal emulators like Alacritty and Foot are two examples of this.
I'm not sure how releasing the source code to a program alters its security state or makes the bugs disappear. Security audits typically rely on binary analysis and runtime inspection rather than source code review, regardless of source model. This is because doing so takes into account things that can violate the contract that is source code: the larger runtime, toolchain bugs, and source code bugs that pass by flawed human eyes unnoticed. Assuming your binaries aren't obfuscated, binary analysis is one thing that is incredibly difficult to hide from. The whole field is actually moving towards stuff like black box fuzz testing; I can guarantee that you can thank that for some of the most significant security fixes you've benefited from in the past couple years.
FLOSS has many merits, but security is lower on that list every year. Proprietary software does not have a monopoly on vulnerabilities.
Also, there is no such thing as a "trusted program" unless you employ formal proofs; Project Everest is one example and their progress pales in comparison to less rigorous TLS implementations. Everyone writes buggy code, and some bugs are more exploitable than others.
Finally, most users do regularly run hostile programs in the form of remote JavaScript apps in runtimes that we call Web Browsers. Browsers use all the OS features they have access to in order to provide sandboxing. On Linux, this includes seccomp for syscall filtering, multi-process isolation, and user namespaces; however, this typically lacks robust GUI isolation on Linux and BSD due to the lack of support in X11. Chromium has a (very partial) mitigation by limiting access to the GPU process while Firefox does no such thing; Webkit2GTK browsers leave you even more exposed as they often disable sandboxing. If open source was perfectly secure, Firefox wouldn't regularly lead Pwn2Own's browser exploits.
This isn't limited to browsers: PDF readers, ebook readers, email clients, media players (ASS subtitles might as well be programs of their own), and countless other programs literally exist primarily to work with untrusted content.
> This means it is impossible to have lower latency if you force vsync (especially if you have unpredictable events like user input).
User input in 2022 is complex work that is far more involved than just printing characters one after the other. Characters interact with each other, modify each other with context, overlap, change each others' direction, and switch meanings. Libraries like harfbuzz are quite advanced. With all this work taking place, vsync does reduce latency by reducing the amount of rendering: vsync allows the rendering to skip changes that don't sync with a display refresh.
> Besides, all the weird "timing solutions" and "offloading to the GPU" you are proposing can be implemented on X11 as well.
Wayland has excellent support for frame timing; X11 just does not. You'd have to break compatibility or layer a more advanced compositor on top, and the latter won't be following any standards that programs can adopt. Wayland standardizes the process so that programs can actually reap the benefits. Terminal emulators like Alacritty and Foot are two examples of this.
Could you give more details on that? This sounds like Wayland is not your favourite...
I discussed this in past comments:
https://news.ycombinator.com/item?id=29017674
https://news.ycombinator.com/item?id=29017940
https://news.ycombinator.com/item?id=29017674
https://news.ycombinator.com/item?id=29017940
Thank you. This is something I will definetely investigate further :-)
It’s much much much more secure. Unfortunately that broke screenshotting/screen sharing programs. So, each compositor has to have their own now. But in general better performance and ideally you won’t even notice anything is different
> So, each compositor has to have their own now.
Not really. There are common APIs called XDG Portals, so all you need is a compositor-specific portal implementation which is transparent for applications.
Not really. There are common APIs called XDG Portals, so all you need is a compositor-specific portal implementation which is transparent for applications.
Basically X11 2.0 in effect. Though I'm sure someone can point out substantial ways they are different, e.g. the new compositor model.
Things are supposed to be a bit more secure and extensible, and it's mature enough now that I've been using it for my daily life with little to no problems for a couple years.
Read this for a better description: https://wayland.freedesktop.org/
Things are supposed to be a bit more secure and extensible, and it's mature enough now that I've been using it for my daily life with little to no problems for a couple years.
Read this for a better description: https://wayland.freedesktop.org/
It's an alternative to the X window system:
https://wayland.freedesktop.org/
Appreciate where you're coming from re the detail. It can be hard to know where to draw the line when explaining projects and it depends on the target audience etc.
In this case, I would say it's ok that they don't explain what Wayland is on the project page. Wayland has pretty widespread adoption now and I reckon the vast majority of people that might be interested in projects like tiling window managers for linux will have heard of it (and that has probably been true for quite some time now, Wayland has been around for over a decade).
If you're keen to dig into it more, another popular project in the space is sway https://swaywm.org/.
https://wayland.freedesktop.org/
Appreciate where you're coming from re the detail. It can be hard to know where to draw the line when explaining projects and it depends on the target audience etc.
In this case, I would say it's ok that they don't explain what Wayland is on the project page. Wayland has pretty widespread adoption now and I reckon the vast majority of people that might be interested in projects like tiling window managers for linux will have heard of it (and that has probably been true for quite some time now, Wayland has been around for over a decade).
If you're keen to dig into it more, another popular project in the space is sway https://swaywm.org/.
Scroll down past the files to the readme. It's not unusual for github links to be posted on HN.
It is a failed attempt to replace X11. The fact that it is more than 10 years in development and Screenshot tools designed for kWin or GNOME won't work on this compositor because there is no standardized API to do such an essential thing should show you how much of a utterly massive failure it is.
Hear Hear. I ask this like every Wayland thread, but what is the point?
I keep hearing all these theoretical answers of things that are broken or could be improved -- but I'm a 20 plus year Linux user who has zero trouble doing work, playing games, including using a setup that uses a 4K monitor; with little or no modifications to standard installs of popular distros.
I keep hearing all these theoretical answers of things that are broken or could be improved -- but I'm a 20 plus year Linux user who has zero trouble doing work, playing games, including using a setup that uses a 4K monitor; with little or no modifications to standard installs of popular distros.
How am I supposed to judge a window manager (excuse me, compositor is the term used in the brave new world of wayland) without a video / screenshot of it running? I get the "tiling" part, but how is this different than sway with a python script telling it to do something on the background?
It's a DWM port to Wayland, essentially. I assume that's why this was posted.
It isn't dwm "port", rather it's an independent window manager with some inspiration from dwm but also from other places. Notably it doesn't share the minimalist design philosophy, it's designed with a powerful configuration and interaction api rather than relying on patches.
dwl[0] is closer to a port, it's explicitly trying to work the same as dwm for wayland with the same philosophy, although it's still an independent project written from scratch.
[0]: https://github.com/djpohly/dwl
dwl[0] is closer to a port, it's explicitly trying to work the same as dwm for wayland with the same philosophy, although it's still an independent project written from scratch.
[0]: https://github.com/djpohly/dwl
Yeah, I didn't mean a port in the most literal sense of that word, so it wasn't a great word choice.
[deleted]
Why does it seem like all new Wayland compositors are tiling? Sure there's Gnome and kWin which are classic stacking/floating windows, but there aren't many minimal light weight non-tiling compositors showing up. Are tiling just easier to write?
A Windows 3.11 or Mac Classic like compositor would be fun.
A Windows 3.11 or Mac Classic like compositor would be fun.
The situation on x11 isn't too different - there's basically only metacity, kwin, and openbox in the stacking WM world, plus a thousand tiling WMs.
In wayland there's additionally KWinFT, hikari, and wayfire. Although neither of them are comparable to the classic Windows/Mac WMs.
In wayland there's additionally KWinFT, hikari, and wayfire. Although neither of them are comparable to the classic Windows/Mac WMs.
There are a ton of small stacking X11 window manager, sure many of them are old, but they're still maintained.
The arch linux wiki has a good list: https://wiki.archlinux.org/title/Window_manager#Stacking_win.... Haven't looked into how many of them are maintained.
https://github.com/labwc/labwc is one I've seen. I don't use these myself, so I can't speak for the quality or anything.
I wish I could have a highly customizable Wayland WM like AwesomeWM or XMonad. I like Sway but it lacks some very important features that I loved in AwesomeWM.
What features are you missing? You could submit your feature request on the swaywm git tracker
Spent a few hours getting this working today. It's still rough around the edges (multi monitor support through a usb-c dock seems a bit finnicky, but that's true of Sway as well), but I definitely see the power of the tagging system over something like i3 or Sway, where windows can only be assigned to one workspace at a time.
I really wish there was a window manager that
(a) looks good and modern (b) can tile well but also allows for free floating windows (c) has simple commands, not multi stroke Emacs-style commands (d) can allow tiling with the mouse with snapping
(a) looks good and modern (b) can tile well but also allows for free floating windows (c) has simple commands, not multi stroke Emacs-style commands (d) can allow tiling with the mouse with snapping
I used to love GOOMWWM[1] and used it for the longest time. I miss a lot of things about it, still. It doesn't quite meet your requirements, looks-wise its very minimal and it doesn't have snapping, but I really liked the idea behind it: make a keyboard-centric stacking/floating window manager that gives you enough control that it can be used as if it were a (manual[2]) tiling window manager. It really feels like a tiling window manager and its fantastic!
[1] https://github.com/seanpringle/goomwwm
[2] I personally use sway these days, but I still prefer manual tiling where I move and size windows myself, rather than having the WM try to do it for me, as long as the WM makes it very easy to do, as goomwwm did (and its predecessor, musca: https://github.com/enticeing/musca)
[1] https://github.com/seanpringle/goomwwm
[2] I personally use sway these days, but I still prefer manual tiling where I move and size windows myself, rather than having the WM try to do it for me, as long as the WM makes it very easy to do, as goomwwm did (and its predecessor, musca: https://github.com/enticeing/musca)
Enlightenment might be what you're looking for (not the old e16 which is still maintained but the successor which was called e17). It has quite a bit of eyecandy, looks good and there is a tiling module.
I developed one for Windows: https://losttech.software/stack.html
i3wm and Sway cover pretty much every base except for (a), if you configure it properly. I'm not a huge fan of the default i3 bindings (feels a little too "Emacs-style" like you suggested), but Regolith Linux[0] has really great default shortcuts that replace stock i3. I heavily recommend checking it out in a VM or Liveboot environment if it's something that interests you.
Have you considered kWin? Sounds like it meets all your requirements.
If you're worried about 'bloat', it's surprisingly lightweight and you don't need to pull in a full KDE desktop environment.
If you're worried about 'bloat', it's surprisingly lightweight and you don't need to pull in a full KDE desktop environment.
Not super worried about bloat, but I do want it to have a Wayland future since X11/Xorg has massive screen tearing on my machine ...
And KDE doesn't wake up properly from suspend on my machine.
:-/
I actually like Cinnamon a lot since you can hit Windows+LEFT/UP/RIGHT/DOWN and at least tile in 4 regions (though I wish it could split more fine grained, and I wish they supported Wayland.
And KDE doesn't wake up properly from suspend on my machine.
:-/
I actually like Cinnamon a lot since you can hit Windows+LEFT/UP/RIGHT/DOWN and at least tile in 4 regions (though I wish it could split more fine grained, and I wish they supported Wayland.
I can't be the only one who is frustrated when they click on a HN link hoping to learn more about something, and instead I'm presented with a list of folders and files.