Title
Back in the day X was a great protocol that reflected the needs of the time.
- Applications asked it to draw some lines and text.
- It sent input events to applications.
People also wanted to customize how their windows were laid out more flexibly. So the window manager appeared. This would move all of your windows around for you and provide some global shortcuts for things.
Then graphics got more complicated. All of a sudden the simple drawing primitives of X weren’t sufficient. Other than lines, text and rectangles applications wanted gradients, rounded corners and to display rich graphics. So now instead of using all of these fancy drawing APIs they were just uploading big bitmaps to the X server. At this point 1/3 of what the X server was previously doing became obsolete.
Next people wanted fancy effects and transparency (like drop shadows). So window managers started compositing the display. This is great but now they need more control than just moving windows around on the display in case they are warped, rendered somewhere slightly differently or on a different workspace. So now all input events go first from X to the window manager, then back to X, then to the application. Also output needs to be processed by the window manager, so it is sent from the client to X, then to the window manager, then the composited output is sent to X. So another 1/3 of what X was doing became obsolete.
So now what is the X server doing:
- Outputting the composited image to the display.
- Receiving input from input devices.
- Shuffling messages and graphics between the window manager and applications.
It turns out that 1 and 2 have got vastly simpler over the years, and can now basically be solved by a few libraries. 3 is just overhead (especially if you are trying to use X over a network because input and output need to make multiple round-trips each).
So 1 and 2 turned into libraries and 3 was just removed. Basically this made the X server disappear. Now the window manager just directly read input and displayed output usually using some common libraries.
Now removing the X server is a breaking change, so it was a great time to rethink a lot of decisions. Some of the highlights are:
- Accessing other applications information (output and input capture) requires explicit permission. This is a key piece to sandboxing applications.
- Organize the system around frames to avoid tearing except for when desired (X doesn’t really have the concept of a frame).
- Remove lots of basically unused APIs like fonts, drawing and many others.
So the future is great. Simpler, faster, more secure and more extensible. However getting there takes time.
This was also slowed down by some people trying to resist some features that X had (such as applications being able to position themselves). And with a few examples like that it can be impossible to make a nice port of an application to Wayland. However over time these features are being added and these days most applications have good Wayland support.
Saving this for later – what a fantastic breakdown. Thanks for this!
Wow this is such a good comment. Very helpful. I wish Lemmy had a “super upvote” where I could upvote it several times.
https://xkcd.com/963/ (October 2011)
[Mouseover text] Thomas Jefferson thought that every law and every constitution should be torn down and rewritten from scratch every nineteen years–which means X is overdue.
You know… That’s fair.
it also means Wayland is due to be replaced in a few years lol
As somebody that first configured X back in 1991, I agree with this message.
To be fair though, with KMS, libdrm, and libinput, setting up X is 1000 times easier than it used to be. I suspect most users never even need to open Xorg.conf or even know it exists.
Ironically, all these technologies are also used by Wayland. A lot of what Wayland does not do, Xorg basically does not do either.
Applications needs some coordination between each other in order to act like you would expect - things like one window at a time having focus and thus getting all keyboard and mouse inputs. As well as things like positioning on the screen and which screen to render to, the clipboard, and various others things.
X is a server and set of protocols that applications can implement to allow all this behaviour. X11 is the 11th version of the server and protocols. But X was also first created in 1984, and X11 since around 1987. Small changes have been made to X11 over the years but the last was in 2012.
Which makes it a very old protocol - and one which is showing its age. Advances in hardware since then and the way we use devices have left a lot to be desired in the protocol and while it has adapted a bit to keep up with modern tech it has not done so in the best of ways. I also believe its codebase is quite complex and hard to work with so changes are hard to do.
Thus is has quite a lot of limitations that modern systems are rubbing up against - for instance it does not really support multi cursors or input that is not a mouse and keyboard. So things like touch screens or pen/tablets tend to emulate a mouse and thus affect the only pointer X has. It is also not great at touchpads and things like touch pad gestures - while they do work, they are often clunky or not as flexible as some applications need.
It is also very insecure and has no real security measures in place - any GUI application has far more access to the system and input then it really requires. For instance; any application can screen grab the screen at any point in time - not something you really want when you have a banking web page open.
Wayland is basically a new set of protocols that takes more modern hardware and security practices in mind. It does the same fundamental job as X11, but without the same limitations X11 has and to fix a lot of the security issues with X.
One big difference with X though is that Wayland is just a protocol, and not a protocol and server like X. Instead it shifts the responsibilities of the X server into the window manager/compositor (which used to manage window placement and window borders as well as global effects such as any animations or transparency). It also has better controls over things like screen grabs so not every application can just grab a screen shot at once or register global shortcut keys or various things like that. Which for a while was a problem as screen sharing applications or even screenshot tools did not work - but over time these limitations have been added back in more secure ways than how X11 did them.
Does that mean that every application will need to be updated to work with Wayland?
In theory yes. In practice most X11 applications can be ran using Xwayland as a compatibility layer
Additionally any application using a GUI toolkit (like kde, qt or gtk etc) only needs to to update to a version that has native Wayland support. Which means most applications already support it. At least if they don’t use any X11 APIs directly (which is not that common).
Not really a GUI toolkit but many many games use SDL and they also gain wayland support with a library update
Yes, nominally, but there is a layer called XWayland to support backwards compatibility, so it’s not really a concern.
Wayland was initially invented for kiosk applications. Then the idea popped up, why not use it for Display Managers too? (graphical login window needs to display somehow) And then the whole thing blew up as a universal solution it was not designed for. So, Wayland is not ideal either.
There’s a very nice (albeit somewhat outdated) talk here.
In a nutshell, both X11 and Wayland are protocols that define how software should communicate to (hopefully) display stuff on your screen.
Protocols as in there’s a bunch of documentation somewhere that says which function a program must call to create a window, without specifying how either program or function should be implemented.
This is great because it allows for independently written software to be magically compatible.X11 is the older protocol, and was working
finegood enough for many years, but has issues handling a bunch of modern in-deman technologies - issues which can’t be fixed without changing the protocol in a way that would make it incompatible with existing software (which is the entire point).
Plus its most used implementation - Xorg, consists of a huge and complex codebase that fewer and fewer people are willing to deal with.Wayland is the newer protocol, that mostly does the exact same thing, but better, in a way that allows for newer tech, and completely breaks compatibility in order to do so.
The trouble with the whole situation was that in order to replace X with Wayland basically the entire Linux graphics stack had to be rewritten - and it was, with raging debates and flame wars and Nvidia being lame.
They also wrote a compatibility layer called Xwayland that lets you keep using older X-only apps which somehow manages to outperform Xorg.Now we’re at the point where major distributions are not only switching to Wayland by default, but also dropping support for Xorg completely, and announcing that they’ll no longer maintain it, which is why posts about it keep popping up.
X11 is an multiple decade old dinosaur, the developer decided it was growing too complex and no longer representing how graphics are done on modern systems and decided a rewrite. While doing so they decided to simplify some things along the way and in doing so they drastically overshoot their target and removed tons of fundamental functions that was present in X11 (stuff like being able to take screenshots, window manager, etc.). Some of that is slowly getting reimplemented and Wayland is getting closer to actually being a feature-parity X11 replacement, but it’s also taken 15 years and is still not done. The whole drama is the conflict between people wanting it as default and the other group of people for which it simply doesn’t work in its current state.
That is partly correct. Wayland is not based on X.org. There is nothing rewritten, removed or simplified. It’s an entirely new design, new code with a different license. And X11 isn’t written by a single developer. XFree86 was started by 3 people, got maintained by an incorporated and then became X.org and sponsored by an industry consortium (the X.Org Foundation). Many many people and companies contributed. The rest is correct. It grew too complex and maintenance is a hassle. Wayland simplifies things and is a state of the art approach. Nobody removed features but they started from zero so it took a while to implement all important features. As of today we’re almost there and Wayland is close to replacing X11.
Also, doesn’t Wayland do things x11 can’t, or did badly, like Variable refresh rate ?
Fractional scaling (per-display), input isolation…
And it will become more as development focuses on Wayland. If you look at X11’s release history, there is (and has been for quite some time) only the most important things going on. That doesn’t necessarily mean things are impossible to do with X11. But it’s just the way things are once something slowly gets replaced by something else.
That is the definition of a rewrite, no? They started from scratch. Otherwise it would be a refactor, cleanup or overhaul.
And yes, it was more than one developer but Wayland was largely started by at-the-time X maintainers.
Hmmh, to me rewriting something means something like writing it again, or revising it. But it’s entirely new, not based on the predecessor, they didn’t have the old code or architecture in mind and it ended up in a different place with different features. So I don’t see a “re-”, just a “write”. I’d say it’s the same category of software (display servers / -protocols) but entirely different and independent from each other. I’d use the word ‘rewrite’ if they were dependent on each other in some form or if one was meant to replicate the other one.
I think that’s generally the point of a rewrite. To start from scratch with a better architecture. If you weren’t changing the architecture then you can probably just keep incrementally improving it.
When you do a rewrite you want to create the same product as before just with better code / architecture. That’s not what Wayland tries to do.
Yes, but the word rewrite implies that it would serve the same function and retain compatibility.
If someone wrote a new implementation of the x protocol, as a drop in replacement for the existing x.org server, you might call that a rewrite.
Wayland is an entirely different solution to the same problem. It doesn’t follow the x protocol, and doesn’t maintain compatibility with the x.org server.
I don’t know that I would say that Wayland is not based on X11. It is a rewrite, not a fork but it is the next chapter of a common history.
Wayland and Xorg do share a lot of code in a way. Libraries like libinput, libdrm, KMS, and Mesa are used by both.
I think @[email protected] did a better job explaining it… It’s a rewrite if you’re trying to create the same product as before. And that’s not what Wayland is trying to do.
I mean we also don’t say a car is a rewrite of a train (or vice versa) but they share some of the same components (wheels, seats, a driver…) And libinput, drm, mesa aren’t copied to the source code. They’re seperate projects and components/libraries that are used via an interface that makes them reusable. Lots of other projects also use the same set of libraries. For example networking. Or games that are built with the same game engine.
Similar to SystemD, a lot of the “other group of people” sometimes are people simply whinging too.
Like I saw one case where someone simply didn’t want to upgrade their workflow… And there were still people talking about Network Transparency as though it is something that has worked well on X11 within the last literally 20 years, or talking about standards.
That doesn’t mean its perfect. But, when you say “feature Parity”, there are features with Wayland which X11 hasn’t caught up with, such as no massive gaping security issues. I’m not sure “feature parity” with X11 is a good idea, because don’t forget, Xorg implements a print server too. A lot of the stuff simply needs to be implemented by the desktop environments.
But I agree, at the moment, its really whether about if we break some stuff temporarily, or keep waiting… In my opinion though, the longer we wait, the longer the transition will take.
Not really. Systemd had the complete opposite problem, it did far more than the previous hackery of shell scripts. The complaints were that it was too big, had too many features, violated Unix philosophy and was less deterministic. Systemd had no problem fully replacing init, cron, DNS and Co. Wayland simply can’t replace X11 in it’s current state, it just can’t do a lot of basic things.
such as no massive gaping security issues.
That’s an utter strawman that doesn’t get any more true by repeating it. Nobody cares about display manager security at this point, since every app you run already has full system access anyway. Wayland security is like making sure the door is locked after the thief is already in the house. It might become relevant in a future when every app you run is in a Flatpak sandbox, but we are a very long way away from that. Even apps that use Flatpak are rarely sandboxed to the point that it would improve security. And on top of that, the sandboxing model Flatpak uses fundamentally doesn’t really work with a lot of Unix tools, e.g. how would you Flatpak something like
make?You haven’t actually read that article which keeps getting reposted did you?
Some of it is stuff like “not all window managers do xxx”, a lot of it is "my specific app (which might even be commercial and rather than bug the company who in paid thousands of dollars, let’s blame Wayland). And yeah, should we wait until every window manager is 100% until we do anything. That’s a generic statement, and they don’t name them for a reason.
Oh, I use xkill, and it doesn’t work. Well yeah, and you shouldn’t necessarily be using it in xorg these days either lol
There are some valid things, but if you read through a lot of the beginning, it’s actually just an opinion running around in circles.
You could literally halve that list pretty easily
And some things like DRM lease, I looked up, and it is supported by xwayland these days.
Some of it is stuff like “if the window manager crashes, you’ll lose your session”. Well yeah, that code would be in xorg instead, so it could crash there instead
Many xorg developers have also basically called xorg hot garbage…
It’s funny how that keep saying xorg supports xxx. But if we look at the history, stuff like compiz and dri and such was basically tacked on. And that’s the problem. Xorg was never designed for GPUs. It was designed for VGA cards like Tseng labs
It does some things better in Wayland already. The 15 year delay was in part because of NVIDIA screwing everyone around, and wasn’t the fault of Wayland
If we’re going to get pedantic about app support like the article, waydroid is broken on xorg as an example…
Actually, looking through it again, and its even more hilarious when I take a second look.
Another good example “Wayland is biased toward Linux and breaks BSD”. The reference is from the NetBSD blog. The Netbsd marketshare is huge, so it’s really important everyone holds back for them. The funny thing is that even gnome is missing features on NetBSD: https://wiki.netbsd.org/GNOME/ . So, should Wayland fix their OS for them?
To be clear for 90% of that whole link you’ve posted, it isn’t the Wayland Development teams responsibility to pick up slack on other projects. It sucks that they won’t be there for the beginning of the transition, but, if we transition earlier, they’ll prioritise getting their crap together
Took me long enough to learn what actually was the issue. Thanks for explaining! :)
On X I can do everything, on Wayland I can’t:
- Enable hardware acceleration in some apps
- Games have greater latency
- Some games shadowing under wayland
- Nvidia sometimes crashes. Their “nvidia-open” driver doesn’t work with Wayland at all
Half of what you said are either issues with your current compositor’s implementation or Nvidia driver related issues, since Wayland on both KWin and Mutter under AMD don’t present any of these issues, atleast for me, while I had the latency issue you mention with my older 3080 card.
The protocol is still under development after 25 years yes, but at the end of the day you vote with your wallet, and Nvidia clearly doesn’t give a shit about open-source or Linux as a whole since we’re a minority.
You’re mixing this around. It’s Nvidia that doesn’t support Wayland, not the inverse.
Bit like saying “Linux doesn’t support Photoshop” instead of “Photoshop doesn’t support Linux”
Nvidia sometimes crashes. Their “nvidia-open” driver doesn’t work with Wayland at all
Really? It’s been working for me since day 1.
Every time I learn more about what Wayland can’t do, I learn of even more critical stuff that doesn’t work
no screenshots? really? who approved this trashfire as default. That’s about as ridiculous as no global hotkeys
That’s not what Wayland is like these days - screenshots etc have been implemented for years now
The point they’re making is that, as a totally distinct project, every single feature had to be implemented from scratch. It’s not a fast process, especially relying on volunteer labour
The issue isn’t just that the features had to be reimplemented, but that they were not part of Wayland to begin with. Wayland does only do the most basic stuff and leaves everything else to the compositor (aka Gnome or KDE). That means every compositor will implement their own hacky version of the missing functionality and it takes ages until that gets unified again, so that apps can actually use that functionality.
Wayland is a classic case of an underspecified software project, they do a thing and they might even do it well, but what they are doing is only a fraction of what is actually needed for it to work properly in the real world. That’s why we are 15 years later and the new “simpler” Wayland is still not ready.
Wayland does only do the most basic stuff and leaves everything else to the compositor (aka Gnome or KDE). That means every compositor will implement their own hacky version of the missing functionality and it takes ages until that gets unified again, so that apps can actually use that functionality.
Would this functionality be mostly the same? Could they get together to make a shared libcompositor that implements the bulk of the functionality? Or is it so tied to specifics of the desktop environment that there’s little commonality. In which case, Wayland not doing it would be the right call.
I think wlroots is the standardized thing. Many WMs use it but desktops need to switch over to it afaik. I think KDE talked about doing this for plasma.
I am unsure what wlroots really is and maybe its not a libcompositor you were talking about but similar.
This is exactly what it is.
It seems very well specified to me, just developers have leaned on X’s insecurity for years to let them just reach across application boundaries freely. That’s addressed by Wayland, but it’s obviously a breaking change that requires new ways of transferring information between apps with oversight from the system, instead of X where all apps could just freely spy on each other. Things breaking and being complex to reimplement is the cost of doing it right.
that’s something
I’ve heard that synergy/barrier/etc doesn’t work though and that is critical for my daily workflow so I won’t be switching until it is supported
I’m confused by this. I’m on EndeavourOS with KDE. It had an all called spectacle which takes screen shots perfectly fine. Does X11 have a screen shot function built in?
With X, any program can capture the entire screen. The Wayland protocol does not allow this, so each DE must implement it separately. You’re using KDE’s screenshot feature, not Wayland’s, and other screenshot tools may not work if they don’t support KDE’s custom protocol for screen capture.
wait so you’re telling me I’m gonna be forced to use spectacle on wayland if I use KDE?
Most applications get their Wayland support from the toolkit they are written in. Qt ( KDE ) and GTK ( GNOME ) apps are going to work in any Wayland compositor.
Some applications do “desktop” related things like try to take screenshots to set global hot keys. Wayland, strictly speaking, does not allow this. This becomes the job of the “compositor” ( Window Manager ) and so, if an application wants to do those things, it has to know how to talk to the compositor.
Increasingly, the desktop environments and compositors are aligning on how to surface some of these capabilities to applications in a common way.
You will have to use a KDE compatible screenshot tool.
sighh, that sucks
does this go for pretty much all programs, like say an email client too? or is there a limit to this?
Does it suck? KDE also has screenshotting implemented. It makes sense that your window manager should manage your windows, which includes being in charge of what can see what. Letting any app screenshot your entire monitor is not secure.
Only those that must interact with non-standard Wayland protocols, such as screen capture tools (like OBS), clipboard managers, WM utilities like xdotool… Other programs such as email clients or text editors are unaffected.
However, this is a non-issue as far as most users are concerned. There are only a handful of implementations (basically, GNOME, KDE, and wlroots which is used by most Wayland WMs) and most modern programs which require specific support to work are all compatible.
I’m told screenshots now work on wayland. The idea was that spectacle would not have worked on wayland because of how locked down it is
I’m on Wayland, KDE plasma with Fedora 39. I take screenshots all the time.
yes, using spectacle I imagine
I use different software, apparently that matters
I understand what you mean now. You have to wait for the software developer to update the tool you use for compatibility with Wayland. Will it run under xwayland?
You said “I learn” twice in a sentence that demonstrates what you do not know. Impressive.
thanks!
I feel like you guys aren’t really “explaining like I’m 5”. Let me show you:
Sometimes, when a mommyboard and a daddy graphics card fall in love, the daddy graphics card puts his connector pins inside the mommyboard’s expansion slot. Then when they both get turned on, millions of tiny electrons surge out of his connector pins and into her expansion slot, where they travel up through mommyboard’s data bus, and into one of her memory cards. Meanwhile, there are thousands of image files inside mommy’s storage drives waiting to come to life, and every once in a while one of them ventures out of the storage drive and into her memory card. And if the electrons and the image file happen to meet at the same time, then 9 milliseconds later, a picture of a baby appears on the monitor!please tag this NSFW
It’s more incestuous than that… It’s a Motherboard with a Daughterboard. 😲
And wayland represents the overly friendly postman that left the house with a satisfied smirk just as the daddy board came home from his hard workday as an xorg liason.
What are you doing, step-board?
Wearing a “hat”!
X (not formerly twitter) is decades old and is built around deprecated ways of doing things as well as a lot of legacy functions.
Wayland is a relatively new project with the aim of replacing X as a more “modern” display server.
Wayland had some stability issues, but they’ve since improved.
I’m sure Wayland is good and all, but I can’t be arsed replacing X yet. I don’t really have any skin in the game, I just don’t replace functioning components just because they’re old (FYI, bash turns 35 this year). While X does what I need it to do, I’ll keep using it. I’ll probably move over when my distro does.
I’ll leave the technical explanation to someone else.
That’s right. To add a few things: X11 isn’t bad. It’s just a big and complex piece of software that has grown for multiple decades. And nobody wants to do big changes or add new things anymore.
Wayland is the modern and “fresh” new approach. I’ve had some issues with my NVidia graphics card. But that wasn’t Waylands fault, but the NVidia drivers. I have a laptop with just Intel graphics and both X11 and Wayland run excellently on that machine.
With Linux we often get many choices, and have several alternatives available to do the same / a similar job. That is a bit complicated for someone new. But we should embrace it, be glad that we can pick whatever suits our individual needs. Wayland still has some issues on a few specific setups, but eventually it will replace X11 as the default.
I remember messing around with font servers 25 years ago in XFree86. Are font servers still a thing with X11?
The X font server has been deprecated like 10 years ago. I doubt you’ll find it as an option in a modern distribution. Nowadays fonts are rendered by the client (application) with something like the Cairo library (if I’m not mistaken).
Yeah. Wayland works great on my laptop. I can’t even log in on my desktop because it’s Nvidia. As a light Linux user the difference doesn’t really mean much to me aside from the fact it doesn’t work on my desktop.
nvidia drivers aren’t THAT bad imho. I just had to experiment with different driver and kernel versions to get my 4060 running properly on my primary PC.
There is t really a whole thing. Wayland is where Linux is going as the people who developed X11 say it is insecure and it’s to hard to fix the issues so they went and started Wayland. They should have called it X12 or something then there would probably be less complaining.
“X12” got a laugh from me. What I don’t get is that nobody is stopping you from working on X11 if you want, so why complain?
Haha that’s my thoughts exactly. Anyone that complains should go try to maintain x11 so they can understand way development is moving to Wayland. I’m not a dev at all and I don’t understand but I love reading the blog post from devs
X11 is like a big dilapidated house. It doesn’t work very well anymore and is difficult to maintain.
Wayland is new modern house. Smaller and more efficient, but missing some amenities that the old house had that some people still want, like a wood burning stove.
Follow-up question, Wayland not adopting those “amenities” is just a feature that is missing right now or it’s impossible to adopt them in Wayland?
Most features missing right now (not all) are against the Wayland philosophy, this doesn’t mean that you won’t get anything but that it needs a “modern era replacement”. Though applications will need to support the replacement. This is usually for good reasons.
The prime example is screen recording. Allowing any program to read and write the entire screen is objectively wrong, no matter what the big time X11 fans say. But there is a replacement: pipewire. Pipewire is extremely advanced and featureful, and it’s more secure because it allows the system and the user to audit who is reading the screen and what part. The problem is that programs need to support pipewire for screen recording, but the main culprits are niche screen recorders (OBS is the best anyway, and it supports it) and proprietary video call software like discord (zoom supports it), which is silly because for electron apps it’s literally a matter of using a version less than 3 years old an adding a flag.
So we can achieve all the missing features by a little twisting, sweet.
but missing some amenities
Like doorknobs or windows. Wayland wasn’t just trimmed down, it was trimmed down to the point of being non-functional and it has taken ages to slowly patch that back up.
walks onto building site
“Where are all the doorknobs?!”
“Trimmed down” is probably not the best way to put it, as it’s not a limited version of X but an entirely separate protocol, so it’s growing from zero rather than shrinking from where X was
X.com is a centralized internet platform that is known for hatespeech, harmful content and being controlled by a single person with questionable opinions.
Wayland.social is part of a federated internet platform that is known for its diverse communities, independence from any centralized authorities and interoperability with other federated internet platforms.
/s
unless you are a developer, there’s not a whole lot to worry about – you’ll switch from one to the other when your distro switches and, chances are, you’ll never notice
the drama comes from the fact that the Linux community loves choices (and arguing over those choices) and, as @skullgiver points out, most of the choices have fallen by the wayside over the years
x is slow and dumb but the standard, wayland is fast and based but still being worked on
It’s not some huge controversy. Almost everyone that works with/on X11 has thrown in with weyland years ago.
I would say that is a false dichotomy. Almost everyone agrees that X11 isn’t the future but the support for Wayland and the specific ways it does things, is not nearly as universal as that. It is just that the problem is huge and has already taken 15 years or so and so it looks like if we want some alternative to X11 that will be done any time soon Wayland is unfortunately the only game in town, no matter how flawed it is.
deleted by creator
I think the main problem is that Wayland is not a drop in replacement.
Every software needs to support Wayland, new environment flags need to be created, flags must be used with electron apps…
Nvidia support has been spotty and some functionality has not yet been implemented. I use a custom .xcompose file, which doesn’t work on electron apps. Let me know if there’s a better way to mimic window’s dead keys.
Overall, it’s hard for an end user to change from a solution that is working perfectly to a solution that requires a ton of work and doesn’t yet have the same functionality.
Everyone can understand that Wayland is the future but depending on your needs and hardware the current experience can be great or terrible.
Sure but as someone starting with a new system Wayland just works. Example multitouch works right away on Wayland and if I remember correctly needs configuration on x11.
“just works” depends on your needs. There is. Polarizing opinion on the Wayland vs x11 because the experiences are also very polarizing.
deleted by creator
I had to set a ton more. Without the ozone flags my electron apps flicker and have this sync problem that appears to eat letters while I type them. Different electron apps use different configuration files, it’s a mess.
I wouldn’t consider my setup to be complex enough for the amount of trouble I had to make the system work under Wayland.
I’m using an Nvidia GPU, I’m sure things would be more streamlined if I had something else.
deleted by creator
A switch from X11 to Wayland is not just a minor change to your workflow though unless you used all defaults before.
It requires you to replace your window manager, all the little tools related to things like clipboard, automation, screen locking,…
And you would have to do pretty much all of that up front to be able to use Wayland long enough to know if it even works on a permanent basis for you. That is a lot of work to put into a project that has a sketchy history of people claiming for nearly a decade now that it works just fine for everything while clearly not working fine for all use cases.
deleted by creator
I was talking about tools like xsel or xclip or clipboard managers for multiple clipboards.
deleted by creator
The point wasn’t so much that there are no replacements, more that every script and every shortcut and everything else using them will have to be changed to work with the Wayland alternative.
It requires you to replace your window manager, all the little tools related to things like clipboard, automation, screen locking,…
You use requires but those are not requirements. It applies to some cases.
That is a lot of work to put into a project that has a sketchy history
Sketchy history? Seems biased.
I’m not a Wayland fan by any stretch, but I’ve come to the same confusion you did. And so has almost everyone else. Which is the real point of my comment I guess.
X is old and works for the most part but fixing stuff or adding features is hard.
Wayland is new and is supposed to be a successor to X, do what it couldn’t do and don’t repeat the mistakes from it. It should be a drop-in replacement like pipewire but isn’t. Features take long time to develop as devs are engrossed thinking of the best solution to make it happen. A lot of proposed solutions are dismissed as well.
I think the drama around Wayland can be explained by the sentence “it should be a drop-in replacement like pipewire but isn’t”.
Without taking a side on that issue, I will point out that this was not a goal for the Wayland designers ( in their own words - I do not have time to go find a quote but have read this sentiment many times ). Wayland detractors agree with your sentence and, given that expectation, are legitimately upset and even confused that Wayland continues to gain mind and market share against X11.
If you feel that Wayland needs to be a drop-in replacement for X11, it is not ready and may never be. By that metric, some people see Wayland as a failed technology and perceive Wayland users as shills and zealots.
If you are interested in a display server that addresses some of the core design problems in X11 and do not mind moving to something new, Wayland is starting to look ready for prime-time.
If you are non-technical and / or unopinionated the debate is probably irrelevant. Wayland will most likely become the default on whatever Linux distribution you use sometime in 2024 or 2025. You will be a Wayland user. Maybe you already are.
If you are willing to step outside the mainstream, using X11 without Wayland is going to be possible for at least another decade. That said, I am saying “outside the mainstream” because not only will popular Linux distributions and desktop environments start to become Wayland only but the innovation is all going to move to Wayland. There will be many Wayland-only compositors, apps, and features. 5 years from now, not using Wayland is going to really limit the desktop experience. I expect some toolkits ( GTK, Qt, and maybe even WINE ) to drop X11 support at some point ( maybe not soon but sooner than 10 years maybe ). 5 - 10 years may seem like a long time but it will likely come faster than X11 stalwarts expect.
X is old and very hard to maintain. A lot of rules about how displays work have changed drastically since X became a thing. X went along with most of those changes, which meant the introduction of more and more hacks to keep it running.
Over time X became worse and worse to work on and people realized that it’s easier to write something new from scratch instead of trying to fix the decade-old technical debt in X.
That new thing was Wayland and over time most if not all people that where interested in working on desktop compositing pivoted away from X.
Wayland (as it is always the case with new software of that size) didn’t hit the ground running. It had various issues at the beginning and also follows a different desig philosophy than X.
Despite a lot of issues being fixed some people are still very vocal about not wanting to use wayland for one reason or another. While some of those reasons are valid, most come from ignorance or laziness to adapt.
