Guide: Full Wayland Setup for Linux(fosskers.ca)
fosskers.ca
Guide: Full Wayland Setup for Linux
https://www.fosskers.ca/en/blog/wayland
135 comments
While I respect Drew's right to keep Nvidia hardware unsupported, doing so cuts out a huge chunk of Linux video game players users. I therefore find it unsurprising that video games have a number of issues that day-to-day use cases don't. Even though this is AMD, lack of Nvidia support keeps Xorg as the default for video games, and this means worse AMD support too.
The main thing up to now keeping Xorg the default for video games was nVidia's lack of Xwayland acceleration support, which made gaming on Wayland largely impossible regardless of wlroots.
And if i uunderstand it right is xwayland acceleration in work for the 470 Driver Release https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
It’s not like a decision based on he doesn’t like nvidia — they would pretty much have to rewrite the whole rendering pipeline for a completely separate model. It simply won’t happen unless the kernel guys can do something and bring nvidia prop drivers to behave well with the kernel abstraction wlroots (and thus sway) sits on top, or someone(s) reimplement the whole thing yet again (and then maintain basically two codebases with twice the bugs)
Personally I don't see how supporting the proprietary nvidia drivers would help my situation as I am using Mesa (and Noveau is supported afaik (?!)) but I assume there is a kernel of truth in there that a lot of people cannot/won't even consider sway because they are on proprietary nvidia stacks.
- I wrote before the edit -
- I wrote before the edit -
Eeh, I did play NS2 some time ago without a black screen. Some games seem to have a focus issue when launched trough proton, though.
I do have lockups on Risk of Rain 2, Deep Rock Galactic and a few others: https://gitlab.freedesktop.org/mesa/mesa/-/issues/864
I thought of using another installation, with and without flatpak, but hadn't thought of launching outside of sway, since the crash issue after a while. I'll try lxqt, which I'm currently falling back to for VR (waiting for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... ).
Symptoms are: a black screen, and nothing responds. No SysRq, no network. Nothings gets written to the logs. I tried leveraging pstore without success. My GPU is an AMD R9 Fury, which I thought was defective (bought refurbished).
I do have lockups on Risk of Rain 2, Deep Rock Galactic and a few others: https://gitlab.freedesktop.org/mesa/mesa/-/issues/864
I thought of using another installation, with and without flatpak, but hadn't thought of launching outside of sway, since the crash issue after a while. I'll try lxqt, which I'm currently falling back to for VR (waiting for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... ).
Symptoms are: a black screen, and nothing responds. No SysRq, no network. Nothings gets written to the logs. I tried leveraging pstore without success. My GPU is an AMD R9 Fury, which I thought was defective (bought refurbished).
OK, re-tested, it also happens on LXQT, so no wayland-related. I still have to test that GPU in another computer to be sure, and also try AMDVLK, though that seems relatively complex with the steam flatpak.
Another frustrating experience was OBS. It would crash quite often due to a bug in qtwayland that someone from the community fixed (can't find the ticket right now) - had to do with too many events queuing up if it was in background and re-focused.
If you read this kind stranger: Thank you so much for this fix!
One thing that doesn't work to this date for me is custom browser docks, which means if you stream and want to interact with your viewers, you need to have a browser open as well :/
If you read this kind stranger: Thank you so much for this fix!
One thing that doesn't work to this date for me is custom browser docks, which means if you stream and want to interact with your viewers, you need to have a browser open as well :/
I have similar issues, those seems to be related to the xwayland implementation of wlroots/sway. I do not have those issues with Gnome on wayland.
Looking at the master branch of the project, it seems that it should get better with the next version.
That's great to hear. I wish they would release more often.
I tried to build sway-git twice during the last 2 weeks. Just from the AUR, because I was feeling lazy after work. It failed twice and I just reverted back to sway 1.5.x because I couldn't bother to learn yet another build-tool and dive into C again. (Yes, I am one of those developers)
I tried to build sway-git twice during the last 2 weeks. Just from the AUR, because I was feeling lazy after work. It failed twice and I just reverted back to sway 1.5.x because I couldn't bother to learn yet another build-tool and dive into C again. (Yes, I am one of those developers)
This is an opinionated guide, hopefully nobody gets the wrong idea like it's actually hard to start using Wayland - for me, switching to Wayland was one drop-down menu option that automatically appeared on my login screen.
It is highly dependent on the user's hardware and software combination.
For example, getting Wayland to work with Plasma on Nvidia graphics cards is still a nightmare, despite it being officially supported. Out of the box, starting a Wayland session just knocks the user into a frozen TTY. Once you get it to work, you quickly learn that hardware acceleration for X11 apps is nonexistent, rendering most video games unplayable.
For example, getting Wayland to work with Plasma on Nvidia graphics cards is still a nightmare, despite it being officially supported. Out of the box, starting a Wayland session just knocks the user into a frozen TTY. Once you get it to work, you quickly learn that hardware acceleration for X11 apps is nonexistent, rendering most video games unplayable.
That’s more of an indicator that plasma’s wayland implementation is not yet ready/stable.
That is why I mentioned it being dependent on the user's hardware and software. "Use a different desktop environment" isn't really an acceptable solution. I don't think it is fully ready until the overwhelming majority of users can move to Wayland without having to give up their current hardware and software.
There is no one wayland. There are many implementations of the protocol, some ahead of the other. I don’t see why wouldn’t it be ready, when out of the 3 major ones, one is not yet there — especially when one of the two working ones (wlroots) is really extensible and anyone can create their own wm/compositor
No Wayland implementation works 100% on an Nvidia GPU yet, they are just in varying states broken. I mentioned Plasma because it is what I have the most familiarity with, but Mutter is only slightly better and Sway doesn't work at all yet.
Totally - the guide is a reflection of the steps that I personally went through to get it all set up. I use tiling window managers, so had to configure everything (the topbar, etc) myself.
> switching to Wayland was one drop-down menu option that automatically appeared on my login screen.
On what distro?
On what distro?
I assumed they meant they used gnome 3+ or kde plasma (or another de) where it's just another option on the login screen.
For i3 -> sway it's not as easy but also not very complicated, nor time-consuming
For i3 -> sway it's not as easy but also not very complicated, nor time-consuming
when you install GNOME 3 these days, does it install both Xorg + Wayland packages, and then at runtime you pick which you want?
I would have guessed the GDM/login manager is X11/xorg?
I would have guessed the GDM/login manager is X11/xorg?
I'm on SDDM, which is still X - getting itself converted to Wayland is https://github.com/sddm/sddm/pull/1367 .
This is the experience on Arch Linux if you use intel graphics, install gnome and gdm, and then start gdm.
For the open source Radeon drivers you have to specifically enable early kms, but I imagine that's done for you with most distributions.
Really, this stuff just works if your hardware is well supported (i.e. - not nvidia).
For the open source Radeon drivers you have to specifically enable early kms, but I imagine that's done for you with most distributions.
Really, this stuff just works if your hardware is well supported (i.e. - not nvidia).
Japanese input begs to differ
I've been using sway a few years already: first in the office workstation with AMD card with Arch, then on my home ThinkPad T25 on NixOS and again on my hobby/travel ThinkPad X230 on FreeBSD that works so smooth and fast now. What's left on xorg/i3 is the workstation with an nvidia GPU, that'll be replaced to an AMD card when the prices come down a bit.
I'm super happy with sway. It's adding all i3 patches into one coherent setup. The community is friendly and helpful and the desktop super snappy and pleasure to use from old laptops to extremely fast workstations.
Thank you for the developers and community.
Edit: dotfiles here https://github.com/pimeys/nixos
I'm super happy with sway. It's adding all i3 patches into one coherent setup. The community is friendly and helpful and the desktop super snappy and pleasure to use from old laptops to extremely fast workstations.
Thank you for the developers and community.
Edit: dotfiles here https://github.com/pimeys/nixos
I'm using nixos with i3 and picom. Is sway with wayland really that much better? What day to day thing would I notice?
It works the same. What I like in sway is it's basically i3 AND i3-gaps together in an active codebase. The biggest difference you notice is when you get rid of picom the compositor, you'll get visibly snappier desktop... Without really needing any special xorg configuration or picom setup, you get composition, tear-free graphics and videos, all just working.
Be aware that to get there, you should make sure you run all your apps in wayland too, not in xwayland. Firefox requires an env var, same goes with GTK and QT apps. Emacs you get from the NixOS overlay; there's a branch that follows the pure gtk build, that doesn't need xwayland. Electron is still xwayland only for most apps. I'm eagerly waiting at least for slack and element to upgrade to Electron 12, which will bring native wayland support.
And there's a nice ecosystem building around wlroots and sway, great tools to choose from for your desktop needs, such as waybar, wofi, wf-recorder and greetd.
Of course you don't NEED any of this. But if I would think like this, I'd probably just used a macOS machine with default settings anyhoo.
Be aware that to get there, you should make sure you run all your apps in wayland too, not in xwayland. Firefox requires an env var, same goes with GTK and QT apps. Emacs you get from the NixOS overlay; there's a branch that follows the pure gtk build, that doesn't need xwayland. Electron is still xwayland only for most apps. I'm eagerly waiting at least for slack and element to upgrade to Electron 12, which will bring native wayland support.
And there's a nice ecosystem building around wlroots and sway, great tools to choose from for your desktop needs, such as waybar, wofi, wf-recorder and greetd.
Of course you don't NEED any of this. But if I would think like this, I'd probably just used a macOS machine with default settings anyhoo.
Sounds good! I just checked around a little bit and the only program I really would like to have wayland support is vscode and that seems to be around the corner. So I will wait for that and then try it out.
Thanks for explaining!
Thanks for explaining!
Wrt SDL2: You can actually replace SDL2 with your own, even if it is statically linked with the game. First, do `export SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0` and then launch your game.
All the gory details: https://www.reddit.com/r/linux_gaming/comments/1upn39/sdl2_a...
All the gory details: https://www.reddit.com/r/linux_gaming/comments/1upn39/sdl2_a...
I went full wayland a few months ago, at first on Ubuntu.
Now, I'm using the early days of the Manjaro Sway Community edition, and it's basically everything that is described in this post packaged and pre-configured out of the box.
https://github.com/Manjaro-Sway/manjaro-sway/
Now, I'm using the early days of the Manjaro Sway Community edition, and it's basically everything that is described in this post packaged and pre-configured out of the box.
https://github.com/Manjaro-Sway/manjaro-sway/
Off topic, but still...
> Alacritty, a modern terminal that "just works"
I find alacritty’s slogan funny, because it’s literally the only terminal emulator I’ve used which has been so full of bugs that I found it didn't work for me and I stopped using it.
> Alacritty, a modern terminal that "just works"
I find alacritty’s slogan funny, because it’s literally the only terminal emulator I’ve used which has been so full of bugs that I found it didn't work for me and I stopped using it.
Haha, it just doesn't work on my old samsung n130 that I still use sometimes, probably due to an unsuported opengl version.
Maybe you tried it really early on? I have had no negative experience with it, and it starts up really quickly.
Marketing 101. (I once saw a brand whose product tiers started with "Premium" at the low end.)
At the end of the day what is the benefit to the layman of being 100% pure wayland?
I really like no application being in control of other windows besides my compositor. As a side-effect to security improvements (clipboard, keylogger, screnshotter), you get:
- Apps cannot arbitrarily modeset (change screen resolution and "mess my desktop up") anymore.
- Under sway, apps are the size I want. I can somewhat resize them over/under their limits
- No more windows that grab the focus and force their way to the foreground
- Apps cannot move my mouse cursor anymore. I hate it when they do, I know some Cadence DKs that do so (position the mouse cursor on the OK button: nice touch, I hate it).
- Some apps/games might have crashed when changing workspaces, but I have never once been unable to "alt-tab" or change workspace, change the screen the app was on, etc.
Granted, under sway those are just different APIs and are not hardened, but they could be in the future. And I mean the above, I've had to restart the X server (or switch to a TTY and kill the app) due to a misbehaving app numerous times, but this is mostly a thing of the past now.
Also, bonus:
- easy multiseat under sway: in under 1 minute, given an extra mouse/keyboard, I can theoretically work with someone else on the same computer: I have a window focused, that I can type in, they too.
- Easily create headless displays, or nested sessions (sway can run as a wayland, X or DRI client). You can use that to leverage another computer as an external display: https://news.ycombinator.com/item?id=25891464
- Under sway, the compositor handles configuring input and display. No more xorg.conf (cue https://xkcd.com/963/ though it's less true these days).
And on the technical side:
- From my understanding, apps should be able to pass GPU buffers around much more efficiently, even drawing directly on the final buffer thanks to dma-buf. This leads to lower-latency and higher performance, especially for high resolutions. In turn, it helps quite a bit with pipewire for screensharing and passing video around, as well as zero-copy hardware video acceleration.
- Apps cannot arbitrarily modeset (change screen resolution and "mess my desktop up") anymore.
- Under sway, apps are the size I want. I can somewhat resize them over/under their limits
- No more windows that grab the focus and force their way to the foreground
- Apps cannot move my mouse cursor anymore. I hate it when they do, I know some Cadence DKs that do so (position the mouse cursor on the OK button: nice touch, I hate it).
- Some apps/games might have crashed when changing workspaces, but I have never once been unable to "alt-tab" or change workspace, change the screen the app was on, etc.
Granted, under sway those are just different APIs and are not hardened, but they could be in the future. And I mean the above, I've had to restart the X server (or switch to a TTY and kill the app) due to a misbehaving app numerous times, but this is mostly a thing of the past now.
Also, bonus:
- easy multiseat under sway: in under 1 minute, given an extra mouse/keyboard, I can theoretically work with someone else on the same computer: I have a window focused, that I can type in, they too.
- Easily create headless displays, or nested sessions (sway can run as a wayland, X or DRI client). You can use that to leverage another computer as an external display: https://news.ycombinator.com/item?id=25891464
- Under sway, the compositor handles configuring input and display. No more xorg.conf (cue https://xkcd.com/963/ though it's less true these days).
And on the technical side:
- From my understanding, apps should be able to pass GPU buffers around much more efficiently, even drawing directly on the final buffer thanks to dma-buf. This leads to lower-latency and higher performance, especially for high resolutions. In turn, it helps quite a bit with pipewire for screensharing and passing video around, as well as zero-copy hardware video acceleration.
The benefit most noticeable to me is the faster user interface.
In my experince X11 is faster (as in latency) when run without any compositor.
This seems critical.
Could be fixed by turning off vsync?
Could be fixed by turning off vsync?
Not entirely. Despite the fact that no available Wayland compositor allows you to disable vsync at this point Wayland also throws away all the work done by ddx drivers on X11 implementing 2D acceleration. This allows X11 clients to de-facto render to directly to the frontbuffer when no compositor is in use. It is the lowest possible latency you can get.
In theory there could be a Wayland implementation that loads Xfree86 drivers, but why? Going forward, the implementations that want high performance and low latency (i.e. VR/XR interfaces) are likely going to target Vulkan, and you will likely never want to disable vsync there.
DDX is deprecated in favor of GLAMOR for acceleration. Which roughly matches the story on Wayland: use OpenGL on the GPU for acceleration.
Then again, Xorg is effectively deprecated in favor of Wayland...
Then again, Xorg is effectively deprecated in favor of Wayland...
I noticed some weird bugs with clipboard sharing, a pure wayland setup avoids such quirks.
* Security Benefits, maybe!
* No more screen tearing
* Multiple Displays with multiple different refresh rates, on some compositors (sway can do it!)
* HWVideo Acceleration for firefox (on some setups)
* it can be faster in some situations
* In the future: More likely support for HDR, VRR etc.
* No more screen tearing
* Multiple Displays with multiple different refresh rates, on some compositors (sway can do it!)
* HWVideo Acceleration for firefox (on some setups)
* it can be faster in some situations
* In the future: More likely support for HDR, VRR etc.
> Multiple Displays with multiple different refresh rates, on some compositors (sway can do it!)
Does this mean we can get VRR on our primary display without having to completely disable other monitors when playing games?
Does this mean we can get VRR on our primary display without having to completely disable other monitors when playing games?
Nice bonus I didn't expect when moving to Wayland: my touchpad magically started behaving waaaay more nicely.
Wayland fixes a number of long standing issues with X, including:
* No screen tearing.
* Better hidpi support including different scale factors on different monitors.
* Improved security, because clients do not have access to all state on the server and servers do not run as root.
Separately, I like how with Wayland the compositor is also the server, so from a TTY you can enter a desktop environment by running a single executable with a single configuration file.
* No screen tearing.
* Better hidpi support including different scale factors on different monitors.
* Improved security, because clients do not have access to all state on the server and servers do not run as root.
Separately, I like how with Wayland the compositor is also the server, so from a TTY you can enter a desktop environment by running a single executable with a single configuration file.
Also better gesture support for touchpads
Can you explain the screen tearing thing? I'm running kwin on X and I don't notice any screen tearing (including doing things like moving windows around rapidly with the "wobbly windows" effect on).
That is because you use a compositor, which composites the screen in a separate buffer before presenting it. But in my experience, there were some edge cases where something like videos would tear.
What happens to your graphical programs when your compositor crashes? At least with X11, if your window manager crashes, your programs keep running (you'd just fire up the WM again).
Sway (the window manager) _is_ the compositor. There is no need for a separate program like compiz or picom.
Yes. That's the problem. Not only is the resulting stack less resilient to crashes, but also it takes away flexibility by needlessly welding together two orthogonal design concerns (window management vs rendering). Sway is like putting X11, the window manager, the global hotkey daemon, screenshot grabber, and so on, all into the same address space. What could possibly go wrong? /s
Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. Like, aren't keystrokes propagated as packets sent through an X11-owned UNIX domain socket in /tmp? Can't we just attach a policy to that socket to decide which PIDs (or process groups, session groups, containers, etc.) get to see which messages?
Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. Like, aren't keystrokes propagated as packets sent through an X11-owned UNIX domain socket in /tmp? Can't we just attach a policy to that socket to decide which PIDs (or process groups, session groups, containers, etc.) get to see which messages?
It's a theoretical problem. The window-management parts of sway are tiny and having them in the same process means you don't have to do IPC every time your windows do something. That simplicity means it's easier to write code that doesn't crash.
Most of the heavy-lifting is done in wlroots anyway. wlroots based compositors really do implement just their own flavour of compositing what you see on the screen on top.
That said, you still can use IPC, if you really want to; I have an external window manager that augments Sway's tiling system via its i3-compatible IPC mechanism to arrange my windows in a way that Sway doesn't do natively. If you really wanted to, there's nothing stopping you from writing a wayland compositor that uses an external window manager.
At any rate, I don't buy the reliability argument at all. I've used sway since 0.10 or something, and I only ever remember crashing it once, and I fixed that bug myself. :P
Most of the heavy-lifting is done in wlroots anyway. wlroots based compositors really do implement just their own flavour of compositing what you see on the screen on top.
That said, you still can use IPC, if you really want to; I have an external window manager that augments Sway's tiling system via its i3-compatible IPC mechanism to arrange my windows in a way that Sway doesn't do natively. If you really wanted to, there's nothing stopping you from writing a wayland compositor that uses an external window manager.
At any rate, I don't buy the reliability argument at all. I've used sway since 0.10 or something, and I only ever remember crashing it once, and I fixed that bug myself. :P
I'd say it's a very practical problem. Why put N different things that used to run in separate protection domains into the same protection domain? Have we gotten N times better at writing code that doesn't crash? Do we believe that we can put N different things into the same address space but somehow ensure that a security hole in one of them won't compromise all of them? Have computers gotten so slow in the last 30 years that doing IPC is no longer an option?
I'm glad that you have personally not encountered a crash in Sway -- I really, truly am. But let's not pretend that a data point of 1 indicates a trend.
I'm glad that you have personally not encountered a crash in Sway -- I really, truly am. But let's not pretend that a data point of 1 indicates a trend.
In practice, placing everything in one process seems to reduce the total attack surface. There is quite a lot of code required to synchronize state between the X server, window manager and compositor. When you combine them, you can throw out most of those bits that are largely serialization/deserialization.
> In practice, placing everything in one process seems to reduce the total attack surface.
Surely you're joking. Privilege separation [1] is a thing for a reason.
If we believed that putting different things into the same address space made them more secure, then why stop there? Why not just put the kernel, the shell, X11, your HTTP server, and everything else into the same address space? Let's just do away with processes -- let all schedulable units be threads that can all read and write to each other's memory, because what could possibly go wrong? /s
[1] https://en.wikipedia.org/wiki/Privilege_separation
Surely you're joking. Privilege separation [1] is a thing for a reason.
If we believed that putting different things into the same address space made them more secure, then why stop there? Why not just put the kernel, the shell, X11, your HTTP server, and everything else into the same address space? Let's just do away with processes -- let all schedulable units be threads that can all read and write to each other's memory, because what could possibly go wrong? /s
[1] https://en.wikipedia.org/wiki/Privilege_separation
There is no real security boundary or privilege separation in that case, the window manager and compositor are getting full access to the screen and the input devices and all the client windows. That's part of the reason why it doesn't make much sense to keep them separated, I know you were joking but it's true: they might as well be threads, it saves you the serialization/deserialization step.
In Wayland, a fail-stop bug in the window management logic will now bring down your compositor and every program that was connected to it. In X11, a fail-stop bug in the window management logic only crashes your window manager -- everything else keeps running. This is a really nice property to have -- in general, why make the "blast radius" of a fail-stop bug bigger when we don't need to?
Like, what's the upside of making it so a bug in the window management logic can crash the entire GUI? You claim latency due to no need for serialization/deserialization across process boundaries, and you claim potentially less-complex code. I'm very skeptical about the complexity reduction -- you're replacing the IPC with global state guarded by critical sections which your threads all need to respect. Getting rid of IPC isn't "free" -- you're replacing it with something that could be even worse. So, I'll need to see some actual case studies here.
I agree that there is measurable latency (context switches and all), but if it's a difference of only a few extra microseconds -- i.e. something the user won't notice because computers are insanely fast these days compared to when X11 and window managers were first written -- then I'm disinclined to give up my crash resilience. Do you have data to show that there is noticeable, irreducible performance lag in having a separate window manager process from a compositor?
Like, what's the upside of making it so a bug in the window management logic can crash the entire GUI? You claim latency due to no need for serialization/deserialization across process boundaries, and you claim potentially less-complex code. I'm very skeptical about the complexity reduction -- you're replacing the IPC with global state guarded by critical sections which your threads all need to respect. Getting rid of IPC isn't "free" -- you're replacing it with something that could be even worse. So, I'll need to see some actual case studies here.
I agree that there is measurable latency (context switches and all), but if it's a difference of only a few extra microseconds -- i.e. something the user won't notice because computers are insanely fast these days compared to when X11 and window managers were first written -- then I'm disinclined to give up my crash resilience. Do you have data to show that there is noticeable, irreducible performance lag in having a separate window manager process from a compositor?
I don't have any raw data for performance numbers and that wouldn't matter anyway because they may not be relevant to your set up; if you're concerned about that you should run a test comparing them yourself on your specific environment. I'm speaking in terms of code complexity here, if you want to follow the threaded approach then minimum two threads will do the job (one for the scenegraph, one for the sockets), and an X compositor should potentially be doing this anyway to avoid lag caused by slow rendering. The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server.
Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...
Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...
> I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs
This can be done via firejail[1] + xpra/xephyr but is a rather cumbersome endeavor. The X11 standard also contains access control hooks that allow you to "firewall" any aspect of your application. However it is used by no application I personally know of and is rendered useless by how the xinput mechanism is implemented at this point.
The reason nobody bothered to deal with this so far is that people almost never run untrusted software on FOSS systems which is what X11 primarily targets. There was no demand.
1.: https://firejail.wordpress.com/documentation-2/x11-guide/
This can be done via firejail[1] + xpra/xephyr but is a rather cumbersome endeavor. The X11 standard also contains access control hooks that allow you to "firewall" any aspect of your application. However it is used by no application I personally know of and is rendered useless by how the xinput mechanism is implemented at this point.
The reason nobody bothered to deal with this so far is that people almost never run untrusted software on FOSS systems which is what X11 primarily targets. There was no demand.
1.: https://firejail.wordpress.com/documentation-2/x11-guide/
The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.
Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.
Trying to shoehorn proper security into X11 would be a formidable effort and still be quite disruptive to client software.
Back when Wayland was just being proposed there were not a lot of developers working on X. They almost-unanimously agreed that it was time to break with backward compatibility and eject a lot of cruft that had built up over the years, such as the horrible font handling. Modern toolkits had already started moving away from using many of these X11 facilities and were doing much more client side anyway. So the argument was that a relatively clean slate design was called for which should dispense with the cruft and better handle client-side rendering.
It's not perfect and I know it is disruptive for some people, but at least here it has led to a much better experience for some years now.
Back when Wayland was just being proposed there were not a lot of developers working on X. They almost-unanimously agreed that it was time to break with backward compatibility and eject a lot of cruft that had built up over the years, such as the horrible font handling. Modern toolkits had already started moving away from using many of these X11 facilities and were doing much more client side anyway. So the argument was that a relatively clean slate design was called for which should dispense with the cruft and better handle client-side rendering.
It's not perfect and I know it is disruptive for some people, but at least here it has led to a much better experience for some years now.
Would addressing the "firewalling" issue be more disruptive than throwing out X11? Because, Wayland definitely firewalls programs (among many other things) -- surely just implementing firewalling in X11 is not nearly as difficult or disruptive? Implementing firewalling could even be done in an incremental way that's easily reverted or tailored to individual apps and users.
I can’t reply to your comment below this, but the Wayland guys are the X guys, and while they are definitely not infallible, don’t you think it is a bit egoistic to think that they didn’t thought of this one simple little thing that you did, without any knowledge on the inner workings of any display server?
I’m sorry if it sounds harsh, but honestly.
I’m sorry if it sounds harsh, but honestly.
Don't get me wrong, I'm not trying to suggest that the X devs are ignorant of this. I too have both deep respect and gratitude for the work they have done and continue to do.
I'm only frustrated that I can't get a straight answer as to what problems Wayland is solving that can't be solved with less difficulty and breakage by repairing X11. I'm sure the X.org developers have an answer, and I would love to know it, but I'm not getting it here in this comment tree.
I'm only frustrated that I can't get a straight answer as to what problems Wayland is solving that can't be solved with less difficulty and breakage by repairing X11. I'm sure the X.org developers have an answer, and I would love to know it, but I'm not getting it here in this comment tree.
I'm no expert in the X11 codebase, but I have lots of respect for the guys who were working on it at the time the Wayland direction was undertaken. So I don't feel in a position to second guess their opinion or tremendous contributions, especially since it has led to a much better experience than I ever had with X.
That doesn't make them infallible. If anything, Wayland smells like yet another instance of CADT [1]. Like, why can no one explain why a world-breaking change like Wayland is justified, when the problems Wayland solves seem like they could be addressed by repairing X11?
I'm honestly interested in building a better X11, and am willing to contribute both time and money. But first, I'd like to understand why the X11 maintainers deemed Wayland necessary -- like, what am I missing here?
[1] https://www.jwz.org/doc/cadt.html
I'm honestly interested in building a better X11, and am willing to contribute both time and money. But first, I'd like to understand why the X11 maintainers deemed Wayland necessary -- like, what am I missing here?
[1] https://www.jwz.org/doc/cadt.html
Maybe that's true if that's your only concern, but there are other reasons to replace X11 than just this.
Also, X11 is arguably not the whole graphics stack, at this point the DRM/Mesa piece is much larger and more significant, and Wayland doesn't replace it outright anyway -- it makes it optional if needed for backwards compatibility, in the same way that macOS has XQuartz.
Also, X11 is arguably not the whole graphics stack, at this point the DRM/Mesa piece is much larger and more significant, and Wayland doesn't replace it outright anyway -- it makes it optional if needed for backwards compatibility, in the same way that macOS has XQuartz.
The other two concerns in GP are no screen tearing, and better hidpi / multi-monitor support. Is it truly less work and less disruptive to address these to concerns within X11 than it is to throw X11 out (and also leave all nvidia users high and dry)? Also, keep in mind that throwing X11 out and replacing it will take more than just technical legwork -- it will also take ecosystem buy-in and standardization, and if we're being honest with ourselves, this is the harder problem. Recall that the X11 ecosystem has a 30-year head start on this, and there's a crap-ton of 3rd party software that assumes an X11 environment that Wayland is going to need to emulate. If X11 does indeed go the way of the dodo, I think we can reasonably expect another 30 years of bug reports in the form of "Fuck Wayland! I upgraded to Wayland and my $IMPORTANT_THING broke!". I very much doubt that at the end of the day the switch to Wayland is going to be overall easier than just fixing X11, but would love to be convinced otherwise.
The usual way to fix other concerns like that has been to add more WM atoms or add more X extensions, which is a similarly uphill battle requiring buy-in and standardization, and typically old X clients just won't be updated to support those new things. The way to get the most value out of such things would be to add support to the major toolkits, but those have already been ported to Wayland for some years now.
The backwards compatibility is done through XWayland which functions similarly to XQuartz, in that it is just the Xorg server running using Wayland as a backend driver.
The backwards compatibility is done through XWayland which functions similarly to XQuartz, in that it is just the Xorg server running using Wayland as a backend driver.
What do you think is more of an uphill battle, in terms of time and energy sunk? Adding another X extension that can be incrementally deployed, or trying to phase X out by maintaining both an X11 and Wayland back-end for all apps trying to avoid breakage?
This doesn't even speak to X11 apps that aren't built with toolkits (for example, I use xterm, xpdf, xfig, Openbox, etc.).
XWayland is a nice idea, don't get me wrong. But it's not a 100% replacement either. Distros offering XWayland are even up-front about it's shortcomings [1][2][3].
[1] https://wiki.debian.org/Wayland
[2] https://docs.fedoraproject.org/en-US/quick-docs/debug-waylan...
[3] https://wiki.archlinux.org/index.php/wayland#XWayland
This doesn't even speak to X11 apps that aren't built with toolkits (for example, I use xterm, xpdf, xfig, Openbox, etc.).
XWayland is a nice idea, don't get me wrong. But it's not a 100% replacement either. Distros offering XWayland are even up-front about it's shortcomings [1][2][3].
[1] https://wiki.debian.org/Wayland
[2] https://docs.fedoraproject.org/en-US/quick-docs/debug-waylan...
[3] https://wiki.archlinux.org/index.php/wayland#XWayland
> Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another.
The response I've heard to this question is entirely nonsensical: it could be done with an X extension, but getting adoption from various parties to make this work would be difficult. As if building an entirely new display system doesn't require orders of magnitude more work and buy-in.
The response I've heard to this question is entirely nonsensical: it could be done with an X extension, but getting adoption from various parties to make this work would be difficult. As if building an entirely new display system doesn't require orders of magnitude more work and buy-in.
Basically everything would stop working with X, because X simply relies on being able to listen to everything. Actually there are nested xservers that do something like this, but now global hotkeys don’t work, it doesn’t have an api for screenshots, so those won’t work either and the like.
And you can probably add some X extension which can’t be queried properly, but then you can just as well create a new display protocol that actually knows about GPUs
And you can probably add some X extension which can’t be queried properly, but then you can just as well create a new display protocol that actually knows about GPUs
I don't care if X sees everything (hell, even if X didn't, the kernel certainly still would). I only care that I can control which programs see which X11 events. Like, my hotkey program can see everything, but my Web browser can only see its own x-windows' events.
There is some rough support for that in the X server, but it is lacking a good API or user interface, and the desktops that would implement that are doing it in Wayland.
Doesn't that strike you as odd? Like, why is it that X11 was so close to fixing the problem, but everyone who would benefit from it (and who touts Wayland's ability to do it) decides to just throw it all away and re-built everything from the ground up? I'd sure like to know what they know about this.
No, the hard part is building a good API and user interface that works for everybody. IMO that's mostly why there are a lot of half-finished and inconsistent things like that X11.
Doesn't that undermine Wayland's selling point of isolating clients' input? No one was clamoring for this until Wayland announced it, and no one was willing to put in the effort to fix it in X11 all these years (even though it would have been easier than ripping out X11 entirely).
I hear you, but a compositor could be multi-process - it was not yet done, but in time it will be.
Which is a mistake. On X11 the server, window manager and compositor are three separate programs. Both window manager and compositor can individually crash, started, stopped and replaced at runtime without any of the other running X11 client instances affected.
On the other hand on X11, Xorg cannot crash without the X11 client instances being affected - a much larger chunk of code. It's only because Xorg is older that that doesn't happen much.
A chunk of code that is running in production for more than 30 years and should be considered battle tested. In my experience Wayland compositors crash much more often than X11 despite the supposed reduced complexity. The last time X11 server crashed on me was in 2004 if I remember correctly.
Exactly, that reliability of Xorg is a function of its age and doesn't imply anything about the correct design of a Wayland compositor. What's the chance those Wayland crashes were in the window management code rather than the rendering, protocol, clipboard, and drag/drop handling code? dwm is 2000 SLOC to Xorg's 1 million or so. I don't think splitting out the WM code would have gained much.
You underestimate the inherent complexity of Wayland. As exercise I recommend to implement a "Hello World" native Wayland client. Watch and see the complexity explode when you simply want to add the functionality to take screenshots to that client.
I'm not sure what kind of "Hello World" clients you're comparing, but if you check the Wayland backends in Gtk/Qt, you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons.
> you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons.
It doesn't seem surprising to me. As X.org has gained extensions over the last 30 years, toolkits that speak X11 find themselves having to decide which extensions they'd like to use. Adding flexibility on this naturally leads to a bigger feature matrix. Of course, the toolkits are also free to drop support for X servers that don't have those extensions, which in turn would shrink the X11 backend.
I have no doubt that in 30 years, they'll have a similarly-sized feature matrix for all the Wayland extensions they'll want to support.
It doesn't seem surprising to me. As X.org has gained extensions over the last 30 years, toolkits that speak X11 find themselves having to decide which extensions they'd like to use. Adding flexibility on this naturally leads to a bigger feature matrix. Of course, the toolkits are also free to drop support for X servers that don't have those extensions, which in turn would shrink the X11 backend.
I have no doubt that in 30 years, they'll have a similarly-sized feature matrix for all the Wayland extensions they'll want to support.
Or perhaps by then we will have moved onto another protocol that's even simpler.
I'm specifically not talking about toolkits. I'm talking about a "simple" native Wayland client. Try to write one and witness utter insanity.
Can you be more specific about what are you comparing this to? An X client with similar functionality would likely be longer and require several X extensions.
What complexity? I have written both a simple wayland client and server — both are simple lib calls.
Also, how often do you write gui apps without any framework? It is absolutely hidden away in both gtk and qt apps.
Also, how often do you write gui apps without any framework? It is absolutely hidden away in both gtk and qt apps.
> What complexity?
What is a wl_registry_listener and why do I need it? What is a simple XGetImage() equivalent on Wayland? On Xlib function names at least give you an idea about what they are supposed to be doing.
> Also, how often do you write gui apps without any framework?
As soon as you have a Toolkit you don't need Wayland anymore. Windows then are just additional nodes in the object tree. There was even a demonstration of GTK applications running in a framebuffer without X11 way before Wayland even existed. If Wayland can only be used sanely with toolkits it indeed is completely pointless.
What is a wl_registry_listener and why do I need it? What is a simple XGetImage() equivalent on Wayland? On Xlib function names at least give you an idea about what they are supposed to be doing.
> Also, how often do you write gui apps without any framework?
As soon as you have a Toolkit you don't need Wayland anymore. Windows then are just additional nodes in the object tree. There was even a demonstration of GTK applications running in a framebuffer without X11 way before Wayland even existed. If Wayland can only be used sanely with toolkits it indeed is completely pointless.
It was some time ago I looked into it, but wl_registry_listener registers a callback for when the compositor “declares” what protocol extensions it supports. This is painfully missing from X, but this makes Wayland much more modular/extensibly.
Wayland’s abstraction is basically a buffer. The client simply creates a buffer either in shared memory, or directly on the GPU and then passes the compositor a handle to the buffer. That’s it.
Also, it is sort of ingenious to compare the two — the XLib is a higher level lib than libwayland. There is absolutely no reason why someone could not create a wrapper for this — although I again ask, how often does one create an only X/only Wayland window without a framework.
Wayland’s abstraction is basically a buffer. The client simply creates a buffer either in shared memory, or directly on the GPU and then passes the compositor a handle to the buffer. That’s it.
Also, it is sort of ingenious to compare the two — the XLib is a higher level lib than libwayland. There is absolutely no reason why someone could not create a wrapper for this — although I again ask, how often does one create an only X/only Wayland window without a framework.
Wayland doesn't have the equivalent of XGetImage for various reasons, but screen capture applications can use the ScreenCast flatpak portal to select window sources: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
I am not sure what you mean by Wayland can only be used sanely with toolkits, any GUI usually need a toolkit or some equivalent, even under X. if you are not using a pre-existing toolkit and are writing your own routines to draw buttons and text boxes and such, that would be implementing your own toolkit.
I am not sure what you mean by Wayland can only be used sanely with toolkits, any GUI usually need a toolkit or some equivalent, even under X. if you are not using a pre-existing toolkit and are writing your own routines to draw buttons and text boxes and such, that would be implementing your own toolkit.
How much of that 1 million lines of code actually gets executed? Also, everyone runs the X server, so its code gets a lot of testing. This isn't true for window managers -- there's a long tail of them. This is just one data point, but in my experience I've had window managers crash far more often than X servers (since they get less love).
Actually most of the crashes I had with Sway were in fact related to compositing and window management. including stupid stuff like crashing because sway couldn't decide which window to focus after hiding another.
Well, the same as when X11 crashes, which happens... Apps lose their connection to X11 and kill themselves promptly, usually.
Screen tearing under X11 is more or less not a problem anymore. HIDPI, yes, but only for multiple monitors (maybe even just programs that don't support it properly ?). Security... eh, yes and no (Xorg can be ran as a normal user).
The actual good thing about Wayland is that it simplifies things. While the bad thing is that it needs some kind of extensions for even the basic things a desktop needs, and that (AFAIK) freeGNOMEdesktop is in charge now.
The actual good thing about Wayland is that it simplifies things. While the bad thing is that it needs some kind of extensions for even the basic things a desktop needs, and that (AFAIK) freeGNOMEdesktop is in charge now.
> Screen tearing under X11 is more or less not a problem anymore.
For GLX/DRI clients where there's an actual concept of swapping buffers w/vsync, sure, but for classical X clients this is not true.
X got extensions for double buffering at one point, but practically nobody uses them.
There is no concept of a "completed frame ready for presentation" in core X, there's no way to really fix this without ceasing to be X (hello, Wayland). X compositors literally just drain event queues of X requests and throw shit on-screen when the event loop gets around to it. If that presents a partially updated window, so be it. GTK+/GNOME folks added "frame clocks" to try work around it, but not everything is a modern-ish GTK+ app, nor do all compositors implement it.
If there's anything Wayland fixes that really required such an upheaval to fix, it's flicker/tear-free compositing.
For GLX/DRI clients where there's an actual concept of swapping buffers w/vsync, sure, but for classical X clients this is not true.
X got extensions for double buffering at one point, but practically nobody uses them.
There is no concept of a "completed frame ready for presentation" in core X, there's no way to really fix this without ceasing to be X (hello, Wayland). X compositors literally just drain event queues of X requests and throw shit on-screen when the event loop gets around to it. If that presents a partially updated window, so be it. GTK+/GNOME folks added "frame clocks" to try work around it, but not everything is a modern-ish GTK+ app, nor do all compositors implement it.
If there's anything Wayland fixes that really required such an upheaval to fix, it's flicker/tear-free compositing.
Well, it seems to work fine (xorg.conf tearfree option, that is). AFAIK wayland compositing also has the problem that clients don't know when they should be done with rendering, as in when the flip is going to happen. I don't know much about how it (wayland, DRI) actually works (as in, can the "client" just render where the compositor told DRI it should without involving the compositor, or does it have to tell the compositor when it rendered).
GNOME3 had(has?) many a timing problems.
GNOME3 had(has?) many a timing problems.
If Wayland is throwing partially constructed buffers on-screen, it's the client's fault for submitting them unfinished.
In X, there isn't really a concept of what a completion boundary is. The client asks stuff to be drawn, the display server gets around to it when it gets around to it, and makes the changes visible willy-nilly, eventually becoming consistent with the client state.
If you look at the source for xcompmgr, the event loop is pretty simple and clearly schedules repainting the root window with all newly received damage updates whenever its X socket is drained of new events [0]. This is a pretty arbitrary boundary to perform redrawing on; process scheduling, socket buffer sizes/limits, it's not well controlled at all. The way this is done it will make visible whatever damage events managed to get into this timeslice. If that results in only part of a window being updated, with the rest of the damage part of that "frame" arriving in the next timeslice, POOF, there's a tear.
[0] https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/blob/mast...
In X, there isn't really a concept of what a completion boundary is. The client asks stuff to be drawn, the display server gets around to it when it gets around to it, and makes the changes visible willy-nilly, eventually becoming consistent with the client state.
If you look at the source for xcompmgr, the event loop is pretty simple and clearly schedules repainting the root window with all newly received damage updates whenever its X socket is drained of new events [0]. This is a pretty arbitrary boundary to perform redrawing on; process scheduling, socket buffer sizes/limits, it's not well controlled at all. The way this is done it will make visible whatever damage events managed to get into this timeslice. If that results in only part of a window being updated, with the rest of the damage part of that "frame" arriving in the next timeslice, POOF, there's a tear.
[0] https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/blob/mast...
There is a wayland protocol called presentation-time that's supposed to provide precise timing information to clients, GNOME just merged support for it two days ago: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484
(AFAIK random clients should not really be using this though, the intent is for it to get used internally by the GL/Vulkan implementation)
(AFAIK random clients should not really be using this though, the intent is for it to get used internally by the GL/Vulkan implementation)
One huge drawback for me is no support for proprietary NVidia drivers.
Thats not wayland though, that the choice of the implementation.
News just came out they will support it in the next release.
Care to share a link? I could only find this: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-D... ? That's already a couple month's old, though.
To a layman none or almost none direct benefits. But there are non-direct benefits like those listed by sibling comments. However it will, in longer term, simplify work for developers, while in short term it will be or rather it is a complication in the transitional phase.
It is an evolutionary step for end users, there is no revolution really. What is the benefit to a layman of a program to change bogies in all trains? He doesn't care about regenerative breaking, so smoother ride? But until almost all of his rides are on this newer platform he would not see a real benefit. Then when it is finally there he will only see its absence. Same with Wayland.
It is an evolutionary step for end users, there is no revolution really. What is the benefit to a layman of a program to change bogies in all trains? He doesn't care about regenerative breaking, so smoother ride? But until almost all of his rides are on this newer platform he would not see a real benefit. Then when it is finally there he will only see its absence. Same with Wayland.
I have Ubuntu 20 and sometimes switch between "Ubuntu" and "Ubuntu on Wayland" and can't tell any speed difference.
Very thoughtful guide. Don't forget to launch dbus and policykit is all I can add.
I've been using sway daily for about two years now. Here are my current gripes:
- Sometimes, client applications do not receive input anymore (mouse/keyboard). This has been a known issue for a while, but I still experience it.
- `dpms off` started to crash my AMD-powered PC some time ago, annoying when I configured it to happen with `swayidle`
- Sharing screen in browsers worked extremely well... last month or so, when it finally got turned on in Firefox. I didn't change my config, but it isn't working anymore. The handshakes happen, but Firefox or OBS display nothing with xdg-desktop-portal
Minor gripes:
- Some Wine (proton) games have trouble getting focused (Sins of a solar empire launcher, Evochron mercenary, IIRC). Other play funny, with screen resolution and mouse coordinates (ashes of the singularity, I think).
- I launch it with `sway`. After Sysrq+R, I often terminate sway by mistake by pressing Ctrl+C
- Very occasional (once every 200 hours or so) crashes. Probably because C.
I've been using sway daily for about two years now. Here are my current gripes:
- Sometimes, client applications do not receive input anymore (mouse/keyboard). This has been a known issue for a while, but I still experience it.
- `dpms off` started to crash my AMD-powered PC some time ago, annoying when I configured it to happen with `swayidle`
- Sharing screen in browsers worked extremely well... last month or so, when it finally got turned on in Firefox. I didn't change my config, but it isn't working anymore. The handshakes happen, but Firefox or OBS display nothing with xdg-desktop-portal
Minor gripes:
- Some Wine (proton) games have trouble getting focused (Sins of a solar empire launcher, Evochron mercenary, IIRC). Other play funny, with screen resolution and mouse coordinates (ashes of the singularity, I think).
- I launch it with `sway`. After Sysrq+R, I often terminate sway by mistake by pressing Ctrl+C
- Very occasional (once every 200 hours or so) crashes. Probably because C.
If you go this "build it piecewise" route instead of a full package DE you'll probably also want notifications, screenshot, a GUI tool for external monitor management (I go as far as using nmtui instead of a widget for networking but absolute detest dealing with sway commands to present on an external screen), battery monitor, and a screen lock/screensaver. Plenty of good options for all the above but sway is not a batteries included DE to choose so you have to find them yourself.
Mostly to learn new things I didn't do any xwayland at all. It's definitely been interesting but certainly not what most would want at the moment IMO.
Mostly to learn new things I didn't do any xwayland at all. It's definitely been interesting but certainly not what most would want at the moment IMO.
For screenshots there are currently two competing approaches. GNOME and KDE have opted for dbus interfaces (e.g org.gnome.Shell.Screenshot) and Sway has opted for Wayland protocol extensions (zwlr_screencopy_manager_v1). I think the former is more maintainable because dbus interfaces are accessible by pure cli tools where grim and wl-clipboard have to create dummy wayland surfaces just to talk to the compositor.
At least everyone agrees on the notification dbus interface and the tooling is super mature.
At least everyone agrees on the notification dbus interface and the tooling is super mature.
Luckily tools are available for all of that, many of them through Sway directly. Interested folks can check out the Sway Wiki.
Yay for wlroots based Wayland compositors!
Besides the tiling Sway there's also the stacking Wayfire[0] that is from the same family, but modeled after Compiz (blur, desktop cube and good old wobbly windows are all there) and highly configurable.
I use it with Waybar[1], wf-dock[2], Sirula[3] as a launcher and a bunch of other small tools like Gammastep[4] (fork of Redshift) for white balance adjustment, grim & slurp [5] for screenshots and mako[6] for notifications. [7]
It's a very DIY-y experience, but it's meant to be (if you want something pre-configured you can barely change try Gnome). The combination of getting it just right and the Ikea effect makes for a pretty rewarding result (I also maintain a list of the available desktop tools you can use when on a wlroots based compositor for your DIY needs [8]). The vision for the future is pre-configured DEs being offered on this base and it possibly even offering a lot of Sway's tiling features. [9]
It still feels like the early days (for non-Gnome), but with Nvidia driver 470 & accelerated XWayland coming up, the Vulkan efforts, Electron (finally) and Wine making the switch I feel fairly confident saying that 2021 is shaping up to be the year of the Wayland desktop.
Free of screen tearing and X-related worries since 2020 :-)
[0]: https://wayfire.org/
[1]: https://github.com/Alexays/Waybar
[2]: https://github.com/WayfireWM/wf-shell
[3]: https://github.com/DorianRudolph/sirula
[4]: https://gitlab.com/chinstrap/gammastep
[5]: https://github.com/emersion/grim
[6]: https://github.com/emersion/mako
[7]: My not-completely-but-fairly Wayfire config https://gist.github.com/solarkraft/f46421295b8c211b2eb56b3ac...
[8]: https://github.com/solarkraft/awesome-wlroots
[9]: https://github.com/Javyre/swayfire
Besides the tiling Sway there's also the stacking Wayfire[0] that is from the same family, but modeled after Compiz (blur, desktop cube and good old wobbly windows are all there) and highly configurable.
I use it with Waybar[1], wf-dock[2], Sirula[3] as a launcher and a bunch of other small tools like Gammastep[4] (fork of Redshift) for white balance adjustment, grim & slurp [5] for screenshots and mako[6] for notifications. [7]
It's a very DIY-y experience, but it's meant to be (if you want something pre-configured you can barely change try Gnome). The combination of getting it just right and the Ikea effect makes for a pretty rewarding result (I also maintain a list of the available desktop tools you can use when on a wlroots based compositor for your DIY needs [8]). The vision for the future is pre-configured DEs being offered on this base and it possibly even offering a lot of Sway's tiling features. [9]
It still feels like the early days (for non-Gnome), but with Nvidia driver 470 & accelerated XWayland coming up, the Vulkan efforts, Electron (finally) and Wine making the switch I feel fairly confident saying that 2021 is shaping up to be the year of the Wayland desktop.
Free of screen tearing and X-related worries since 2020 :-)
[0]: https://wayfire.org/
[1]: https://github.com/Alexays/Waybar
[2]: https://github.com/WayfireWM/wf-shell
[3]: https://github.com/DorianRudolph/sirula
[4]: https://gitlab.com/chinstrap/gammastep
[5]: https://github.com/emersion/grim
[6]: https://github.com/emersion/mako
[7]: My not-completely-but-fairly Wayfire config https://gist.github.com/solarkraft/f46421295b8c211b2eb56b3ac...
[8]: https://github.com/solarkraft/awesome-wlroots
[9]: https://github.com/Javyre/swayfire
Why is wayland better X, sorry i dont know well desktop linux,
> Sway is a tiling window manager [...] written in C, and thus is very fast and has little resource overhead.
So is GNOME as far as I know.
So is GNOME as far as I know.
It is a common misunderstanding that all C programs are fast by default. In reality that's not the case. It takes hell a lot of time and resource to get that right. C programs just compile blazing fast. D compiles even faster.
Also, IMPO, GNOME is crap and GNOME != sway.
Also, IMPO, GNOME is crap and GNOME != sway.
GNOME has enough Javascript scattered throughout that I wouldn't call it a C program, even if large chunks like Mutter mostly are.
Gnome is not a tiling window manager.
But it can be with a touch of Pop Shell! It comes out of the box in Pop!_OS, which is Ubuntu plus GNOME plus extra features.
I never use GNOME but I decided to try it to test pop shell awhile back. This was shortly before 1.0 of pop shell so it could have changed. Not trying to disparage it, just sharing my experience as an i3 user. It feels so so slow because of animations.
I googled how to get rid of animations because it wasn't in the GUI settings. Animations were removed, but a delay remained with any tiling movements where an animation would have been. Not sure if this is a limitation of GNOME or a bug in pop shell, but it wasn't going to work for me. It would be really hard to give up the snappiness.
I googled how to get rid of animations because it wasn't in the GUI settings. Animations were removed, but a delay remained with any tiling movements where an animation would have been. Not sure if this is a limitation of GNOME or a bug in pop shell, but it wasn't going to work for me. It would be really hard to give up the snappiness.
Isn't gnome a big pile of JavaScript these days anyway?
Yes, as is Pop Shell implemented on top of Gnome (mentioned in another comment).
You can tell they've made some questionable decisions when you try to use Gnome on very weak hardware.
On an old dual-core Celeron w/ 2GB memory I found it unusable. KDE—which, when I first started using Linux desktops on machines less than 1/4 that powerful, was noticeably heavier than Gnome—was a little slow but basically fine.
To my eyes gnome also drops frames like crazy (like, even for Linux, which is a pretty jittery environment to begin with) even on excellent hardware—not sure, but I think it's a reasonable guess that's also a symptom of sprinkling a scripting language all over the system without incredible levels of discipline to make sure it's never in the way of anything important.
Webtech strikes again.
You can tell they've made some questionable decisions when you try to use Gnome on very weak hardware.
On an old dual-core Celeron w/ 2GB memory I found it unusable. KDE—which, when I first started using Linux desktops on machines less than 1/4 that powerful, was noticeably heavier than Gnome—was a little slow but basically fine.
To my eyes gnome also drops frames like crazy (like, even for Linux, which is a pretty jittery environment to begin with) even on excellent hardware—not sure, but I think it's a reasonable guess that's also a symptom of sprinkling a scripting language all over the system without incredible levels of discipline to make sure it's never in the way of anything important.
Webtech strikes again.
Since a few months I noticed weird (complete) freezes/crashes on my pc, while gaming... it's not the youngest so I thought it may come to end of life.
Out of curiosity I reinstalled i3 a couple of days ago and used it (only) for gaming. No crash since.
I assume it's either a bug in Mesa (AMDGpu) or somewhere in the wayland stack... sway hasn't had an update since November, so... I dunno, I haven't taken the time to investigate.
While working I still use sway, because I've customized it to my needs, but for Gaming/Streaming I now switch to i3 again.
Nice sideeffect: I can finally play some games again that wouldn't even launch on Sway or were unplayable, like e.g. Natural Selection 2 which turned to a black screen when I switched workspaces (e.g. from one monitor to another) to e.g. tune down the music or scroll down a page while being dead.
Feels funny, but more annoying :/