Because after so many years, a lot of the ecosystem hasn't moved, or is even not compatible with it. Good multi display support is missing, and some games don't render well.
I want it to succeed, and the project has been progressing non-stop, but it does show how much time and energy such an endeavor takes. I was expecting to be able to use it for years and years.
See also: BTRFS
- Tear free rendering and capturing.
- (Small) improved performance.
- Games are much better behaved. I can reliably window, maximize and full-screen them. They also never mess with the display resolution.
- Seems to have less windows (especially hover tool tips) just hanging around. I guess the compositor can close these at the right time under Wayland.
- Proper secure screen locking. (I think GNOME + GDM can do something safe on X but most display managers + lock screens can't cooperate well enough to manage this.)
Honestly it is nothing major (except the mixed dpi stuff) but a nice step up. And if the X devs say that X is unmaintainable and this is going to lead to many improvements and be able to be maintained for the next age of displays on Linux I'm happy to make the switch now that it is the default and I am not aware of any problems for my workflow.
I think screenshots work out-of the box for most compositors and screenshot tools but depending on your distro you may need to configure xdg-desktop-portal for screen recording. On my distro (NixOS) this seems to work on GNOME with no additional config.
For NixOS configuring GNOME which uses Wayland by default (if your GPU supports it) is just:
services.xserver = {
enable = true;
displayManager.gdm.enable = true;
desktopManager.gnome.enable = true;
};
The reason it takes so much time is not that is requires a lot of "energy" or that the problem in general is particular hard to solve. Wayland is fundamentally flawed at the concept level and the only way for it to get to a usable state is to turn it essentially into another X. Combine this with general stubbornness of all involved parties and the extreme hesitancy to standardize essential things you get a recipe for disaster.
This is a fallacy.
If I start making wild claims about cardiology, you'd be correct to ask me for some credentials.
And yes, it is the fallacy of credentialism to attempt to use that as a measure of authority to make a statement. I could be a kernel developer of 20 years experience and have been terrible for all of them.
Whether the whole ecosystem is already in place to move regular users over is another matter (I'm developing a Wayland compositor at work and even I am still using X11 on my workstation), although with this kind of project I guess you just need to face the chicken-and-egg problem at some point to actually move things forward.
Not a problem with Wayland, it's just as you say, not there yet.
The difficulty arise from the complexity of the problems to solve.
In a x11 world, the assumption is that everything that a user runs is fully trusted, any software has access all the inputs, all the audio, everything that is displayed without any restriction. This wasn't a problem 30 years ago, but is quite a blocker for modern approach to security with granular permissions.
The architecture of x11 itself does not fit a modern graphical stack, some problem cannot be solved properly like monitors with different framerates, fractional scaling etc...
Wayland is just one part of the big efforts that are ongoing to address those issues. This impact the whole desktop ecosystem, it's a massive effort.
Wayland will replace X though indeed (coupled with other things) that's the intent.
What problems are those exactly? It's my impression that Wayland (the protocol) just creates problems without solving any.
> Wayland is just one part of the big efforts that are ongoing
Yes. The anti-user anti-general-purpose-computing anti-freedom efforts. Trying to create a world where device owners may use their devices only for a set of approved actions such as browsing Instagram and Tiktok. When someone speaks against it, they are attacked with FUD, and "security" is called upon. Does that remind you of anything?
Some relevant past comments:
https://news.ycombinator.com/item?id=26753902
https://news.ycombinator.com/item?id=26758783
Yes, looking just at big DEs there's not much difference. Consider, however, the problems Wayland causes for the ecosystem. Take screen grabbing programs or input event interceptors like xdotool. There's simply no way to implement one of those strictly on Wayland. Each Wayland compositor must be targeted separately instead.
This is discussed in some of the threads I linked to, BTW.
The portal for xdg-desktop takes care of the implementation and is the responsibility of the compositor.
It's already used by Flameshot for example.
There is several xdottool equivalent as well: https://github.com/atx/wtype https://github.com/ReimuNotMoe/ydotool
This one is specific to wlroot based compositor: https://git.sr.ht/~brocellous/wlrctl
The current ydotool goes in another direction, it tries to be independent of Wayland, but this also means it doesn't know your keyboard layout, making it less useful. It also requires a privileged daemon running on my system, something I wouldn't give to such an obscure project.
These problems don't even exist for X11 users because implementing such functionality is easy because it's supported by X.
2. You respond by giving a bunch of examples that align with my statement, but you don't seem to realize this.
3. I clarify.
4. Suddenly I don't operate in good faith?!
What's worse, your replies attack straw versions of my comments: https://en.wikipedia.org/wiki/Straw_man
> a form of argument and an informal fallacy of having the impression of refuting an argument, whereas the real subject of the argument was not addressed or refuted, but instead replaced with a false one
I'm not refuting anything you still haven't brought any argument at all :D
The protocol doesn't support most essential features, leaving them up to "compositors" to implement mutually incompatibly. Screenshots, accessibility, etc.
Thus Wayland promotes fragmentation and death of the Linux desktop.
On top of not actually solving problems, the protocol manages to be too opinionated, forcing compositing on the user.
Other desktop environments shifted to compositing 15 years or longer ago since it performs better on modern GPU's than the old 'damage check and repaint' algorithms. I don't think it's impossible to do that with Wayland, but since nobody tried to build that I think interest is very low.
First of all, what is dead may never die. Second of all, no, it is false. The core protocol is indeed small (unix philosophy ain’t a good thing now for some reason I guess?), but the extensions are easily queriable and they undergo standardization if they are deemed useful. Would you prefer a single entity giving directions on what has to be included? That would seem pretty antithetical to the whole bazaar style of development.
I'm using Gnome 40/Fedora 34 with laptop and attached 4K display. Gnome apps works absolutely fine. Some non-gnome apps do not re-scale when moved between displays and that's the only issue that I've found.
Also I run Factorio absolutely fine. No idea about other games, though.
You must perform regular maintenance on btrfs or it will quite simply break. This is a huge departure from for example ext4, which is (to the end user at least) hassle free.
- a few years ago, one system would suddently not boot (due to btrfs); this happened twice
- nowadays, on one system, background scrub doesn't start
This is anecdata of course, but I've never had a good impression overall. I don't see any reason to use btrfs rather than ZFS, considering that Ubuntu and derivatives are starting to add builtin support.
Scripts for actually doing so can be found f.e. here: https://github.com/kdave/btrfsmaintenance
Actually the fact that X11 can be used today despite the fact that we went through several cycles of vastly changing GPU hardware shows that it absolutely has stood the test of time.
The X server became a pretty useless middle man between clients and the compositor. And the vastly changed GPU hardware is the reason we should prefer a superior solution - we no longer draw as we did 3 decades ago, so we should cut out the middle man.
Terminal applications stood the test of time as well. For everything that is not graphical in nature they are indeed good solutions.
> The X server became a pretty useless middle man between clients and the compositor.
X is a middle man but far from useless. Just as Wayland is a middle man as well. And looking at the protocol actual access to GPU memory is more opaque on Wayland than on X11 and as such to me Wayland is a more intrusive middleman.
If you want to "cut out the middle man" you have to use DRM directly.
Wayland is not a middle man as it is the compositor itself as well - it does the minimal amount of work necessary to compose the desktop. X on the other hand just transfers messages between clients and the compositor without doing any actual work (x render functions are almost never used by modern applications)
Also, DRI3 doesn’t solve the fundamental security flaw of X - which can only be solved by nesting multiple X servers into each other. At that point we would have a much uglier architecture than we have with wayland.
But the problem is basically: you can either have 1-2-4-8 cores at most writing pixels into a buffer one after another (but due to the complexity of interactive GUIs it will most often be single threaded), so a circle will be displayed as going over an area and coloring each pixel.
Versus specifying some condition and having the GPU run it on every pixel in large batches, almost doing it in one go. Of course for 3 lines, what previous GUI iterations were, you don’t need gpu, but for gradients, media!, and basically a bunch of other things you simply need the GPU’s orders of magnitude more parallelism. Add to the picture that we are using much bigger screen resolutions (full hd has 6x number of pixels compared to 480p, and then we are not even talking about 4k. And 120, 240fps monitors are a thing now) and you can quickly see that 1) drawing is a greatly parallelizable task 2) having it done serialized simply doesn’t scale to today screens.
This is because said graphical applications are designed to be used with a modern GPU and they use stuff like OpenGL to render their components.
"but for gradients"
Maybe we can go without them. Modern UIs are too heavy, latency-inducing, battery consuming, and can turn your device into a heater easily.
"And 120, 240fps monitors are a thing now"
Re-drawing the window in every frame is a wasteful action that tends not to happen with applications designed for software rendering.
While you may not like gradients, animations (which absolutely mandate GPUs) for example do give context on what happens because humans are used to physical objects that don’t teleport from one place to another. I wouldn’t consider these needless features either.
And, may I ask,why are you so quick to dismiss the core developers of X?
Except new GPU hardware at reasonable prices has been unobtainable for 2 years now, and AMD's new Linux friendly stance was only a couple of years before that. So there's like a 2-3 year window where you could have said "Well, you should have known to buy the FOSS friendly hardware". (Which came with other tradeoffs, AMD had uncompetitive hardware and poor GPGPU support in that time period)
I have seen various comments claiming that the code was very clean.
"Since the late 00s, all of the window managers had already started doing compositing themselves"
Most window managers don't do compositing.
Also, XCB is async.