It's at least 2 decades old, if it was ever a real problem in the first place.
It definitely used to be a huge pain in the arse. There used to be pages after pages after pages of random "HOW TO ..." style guides for people to configure X11 config files around the net (many just working for specific hw).
It was an incredible mess, with pretty much nothing positive about it. ;)
But it was indeed around 20 years ago that it was an issue.
X has a lot of code in it which needs to be elsewhere in the design envisaged for Wayland. Once support (for example, for kernel mode setting) is available for Wayland to use it, it makes a lot of sense to also use it with X.
With a compositor other than the Gnome one?
Is that using the Gnome compositor?
Or is all maths broken because I found a calculator that doesn't have a working addition key?
Having to worry if your WM supports your GPU is like having to worry if your web browser supports your NIC
A wm has always been trivial compared to a display manager, people just mistake one for the other.
Qt/KDE is lagging behind and there are no easy way for them to catch up. Had the display server been a single implementation, Qt/KDE can focus on WM/Widget..
They want to have everything built in-house, they could join forces with Sway/WLRoots but when approached they declined.
I am fine with having multiple implementations, we don't want to get stuck with a defacto standard, but don't blaming KDEs choices on Wayland.
Wlroots is there for those who wants it and can agree with its design tradeoffs and it is used by plenty niche wms, so I think we have it as good as is feasible in a bazaar style, “everyone works on what they like” fashion. Without a higher power to spearhead a single project there can’t really be a difference.
* A set of utility X applications, like a panel and launcher
* A recommended window manager
* A recommended display manager
And then this all runs on top of a separate X display server
Generally the last two are easy to replace, for example I have used both Compiz and Xmonad on Gnome 2 and XFCE. Gnome was probably a bad example for me to pick since modern Gnome does merge the first two bullets into one, but it's still separate from the display server and can be launched from other display managers, or none (just startx)
Again, it would be like Firefox needing to talk directly to my network card rather than the actual packet sending be managed by the layer below (the OS in that case)
Gnome/KDE/wlroots are akin to separate browsers implementing the same (HTTP) protocol. It’s a lot of work, plenty choose to rather fork an already existing code base (chromium based ones), but with time people will consolidate on a few ones. But you surely wouldn’t want an all-Safari, or all-Chrome browser “ecosystem”, right? (Though unfortunately we are not far from the latter). That’s what Xserver gave practically.
[1] There is some compatibility but let’s forget about that for now.
I think this is the point, but maybe in the opposite way you mean: X was the wrong architecture for what we want to achieve with a display system these days.
Some of that is about security, some of that is about which piece knows about what is responsible for what to make the system work. Wayland changes the responsibilities significantly. This is a GOOD thing - it's why things like HiDPI can be made to work in Wayland and fundamentally don't in X (unless you control a lot of variables very carefully).
They don't have the financial backing that Gnome does, but doesn't accept itself as a smaller project.
Such as having a modern wide gamut/HDR display, or a display without a blue spectrum spike. Or printing anything in color. Or doing photography or digital painting.
It's fine to have the "works on my machine" attitude for a user discussing this on the web. I just hope the devs of what is being pushed as a replacement for what works don't have it. (and the signals aren't good)
The people "pushing" Wayland are the people who previously worked on X. They stopped because it's ancient, broken and untenable.
> However broken the past was, replacing it with something that is similarly broken but in different non-overlapping ways is not the proper way forward.
That "opinion" is well founded. Most people don't care about network transparency (to pick one example), and those that do can club together and keep X alive. Or write an extension for Wayland. Open source is easy in that it gives you many chances and ways to contribute!
Personally, I'd prefer those "LOOK IT'S MY DESKTOP OVER THE INTERNET" people kept their weirdness out of my compositor, but that's just my take.
- Screenshots and sharing the screen;
- Global hotkeys;
- Alternative / switchable / tunable keyboard layouts and input methods. Not fancy stuff, just, say, typing Latin, Cyrillic, Greek, and Japanese characters.
All these things are is some sort of disarray under Wayland currently. Once they are properly implemented, I may consider switching.
I want Wayland to succeed. But it's not entirely there yet.
Works for years.
And global hotkeys are not trivial - no, that “everything listens to everything” that X did is not a proper solution.
I get that people pretend they are afraid some nefarious program is going to scrape their screen, but since I don't use closed source software this just isn't a real worry.
Also do keep in mind this is about more than global hotkeys; there are several accessibility paradigms that simply don't and can't work on Wayland.
It never worked "fine", it was always a failure from security and usability perspective.
> I get that people pretend they are afraid some nefarious program is going to scrape their screen, but since I don't use closed source software this just isn't a real worry.
You know that apps have security vulnerabilities that can be exploited over the network? Screen grabbing, keyloggers, input injection(you have open root terminal? let's type some commands there). And more.
Do you personally audit the source code to every piece of software you run on your computer? Do you have the expertise necessary to even do that if you wanted to?
FOSS isn't magically immune to security exploits. Everything we build should assume any other software it interfaces with might be defective or even hostile.
No more than Wayland users have audited the process protection code.
I was illustrating why Wayland's security paradigm is important. It doesn't assume all the apps it renders are safe. It can still (and probably does) have security holes, but it is already starting from a much more secure foundation than X11 ever had any hope of having.
Similarly, my web browser probably has not publicly known exploits that I haven't bothered to discover myself, but that doesn't mean I should be OK with using a browser that doesn't sandbox its javascript engine.
A malicious PDF file is enough to break havoc with a simple memory bug, so unless you claim that open source is also bug-free, or that you don’t use any external data (but visiting this site already invalidates that assumption), then you are just being naive.
There is nothing inherent that couldn’t work with Wayland - there is nothing preventing the relevant teams agreeing on a new interface to broadcast accessibility information to the wayland server, that can thus share that with specific accessibility software (which is explicitly permitted to do it).
Ideally, what you want, is for the client expose a set of (described) actions, with suggested key bindings. Users can then enable / disable / change the bindings in some central place, which would also take care about collisions, reserved global keybinding or reserved local keybinding (key shortcuts, that are always supposed to be available to the focused app).
Here's a screenshot I just took on my plasma / wayland desktop.
Here's a screenshot of me sharing a window in firefox:
> Global hotkeys
I use global hotkeys to switch between keyboard layouts, see the screenshot. Works fine.
> Alternative / switchable / tunable keyboard layouts and input methods. Not fancy stuff, just, say, typing Latin, Cyrillic, Greek, and Japanese characters.
I use global hotkeys to switch between keyboard layouts, see the screenshot. Works fine.
> All these things are is some sort of disarray under Wayland currently
This all basically worked out of the box. I'm really not seeing where this disarray is. Have you actually used wayland, or are you regurgitating taking points from 5 years ago?
You forgot to mention that it doesn't work without portals and Pipewire dependency, and portals have to be implemented individually for each DE.
> I use global hotkeys to switch between keyboard layouts, see the screenshot. Works fine.
Because the KDE developers went to a lot of effort to make it work. That doesn't mean it will work well in other DEs and that is Wayland's problem.
If the maintainers of the DEs are happy with the effort, then I don't see a problem? (unless you're a DE maintainer, in which case - fair enough).
[1] When I first wrote this sentence I wrote "X is hard to implement" using X as a metasyntactic variable before I realised that was incredibly confusing in context!
- that color management is needed for a tiny subset of users (those weird guys with printers and calibrators...).
- that it can be delegated to 3rd parties or implemented later when the time comes.
Neither of that is true. Color management is just another word for correct rendering of everything that comes through your stuff. Every pixel must have a well defined path from the physical input to the application to the physical output, you can't just implement a part of it and move everything else out of scope. To display anything in HDR, you have to build your entire pipeline around color management from the ground up.
The reason you are ignoring it is that you're using an sRGB display, in any other case it would be immediately apparent to you. sRGB also needs color management but everything assumes sRGB so you're able to mostly get away with it. This no longer holds in the modern hardware. You need a properly managed pipeline for gaming, movies, web, YouTube, GUI, smartphone family photos, and basically everything else.
Wayland developers actually found it the hard way, and are trying to implement it for, what, 3 years? That this wasn't a feature of a display server protocol from the start is a massive design flaw.
Same with the input methods handling being forced to be lumped up together in the downstream software, without at least specifying how it should be done. They took a well understood problem, and moved it out of scope; it might not have been an issue, but the lack of a spec will lead to fragmentation and less options. This affects most of the userbase, not "weirdos with remote desktops".
Should colour management be in Wayland? Sure. Could it have been designed better to cater for it? Absolutely. Wayland's got its warts, sure. But for most people it's good enough, and that's what matters in software. It'll get fixed, and the more people who care about it actually contribute, the faster it'll get fixed. Open source is amazing!
Color management is need for full HDR support, it uses Wide Color Gamut instead of sRGB
For some people, Wayland isn't there yet. For a whole lot of other people, Wayland is already better than X. Are distro developers supposed to ignore that and keep pushing X, despite it being the worse option for most of their users? Isn't it enough to provide X as an option for people who need something Wayland doesn't do yet?
Plus, Wayland is getting better, X isn't.
Maybe. I just hope the transition is more smooth, and the wayland fanboi don't try to belittle X users.
There you go again with your mythical screen tearing that I've never seen.
You should learn to enable V-Sync in your compositor or in xorg.conf (the option is called Tearfree in Mesa).
> the screen locker doesn't even engage if you have a context menu open
For some reason, it worked for me.
sleep 5 && xflock4
then I open the context menu and wait 5 seconds. After 5 seconds the screen locks successfully.
> vital things like compositing are hacked on in janky ways
Bullshit. Compositing in Xorg is done properly and it's not mandatory in cases where it's not needed. Besides, the compositor in Xorg can be changed to any other compositor regardless of the window manager (exceptions - compiz).
> For some people, Wayland isn't there yet.
Essentially all people who use their computer for more than just a Google Chrome launcher.
> Are distro developers supposed to ignore that and keep pushing X, despite it being the worse option for most of their users?
The only thing that works in all use-cases is Xorg.
> Isn't it enough to provide X as an option for people who need something Wayland doesn't do yet?
Thank you, but no.
> Plus, Wayland is getting better, X isn't.
No, it's not improving. It's adding more crutches, we haven't seen such crutches even in Xorg.
I'm happy for you that you get a tear-free X11 desktop. A quick Google search should make it obvious that I'm not the only person who experiences tearing with X though.
I don't know the details of your system, but the screen locker issue seems to definitely affect xfce4-screensaver; this issue is still open: https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/75. And just for fun, here's the same bug for Ubuntu (just for a different screen locker): https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/..., still open. Maybe try to follow the reproduction steps listed in those two issues and see if you're affected or if your system is magically immune. Maybe inform those projects that the issue is fixed?
Finally:
> The only thing that works in all use-cases is Xorg.
Xorg doesn't work for my use case. I have multiple monitors of different refresh rates and different DPI settings and I demand a tear-free desktop, Wayland is the only option which works for that use case.
Not sure that anybody who "has a problem" has stepped up to really do much about it (most X development in the past few years is to support Xwayland), so it can't be that much of a problem.
Did you reply to the wrong comment? How does this address what I wrote?
> If I had to guess I would guess that when Linux distro grow tired of the new shiny they will switch to a port of Xenocara for their display systems.
Linux distros are not going back to Xorg. Xenocara is basically just that adapted to OpenBSD, but all the Xorg developers remaining pretty much work for Linux distros so if they did go back they would just switch to what they already package and ship today.
There never going to fully "leave" Xorg (Debian still ships token ring software FFS so the idea that they'll stop shipping X is just a weird fantasy some people have for some reason) so in that sense they won't "go back". Void is already working on packaging Xenocara and I doubt they'll be the last one; OpenBSD will just become the team that provides both a display server and a secure remote shell for lots of the Linux ecosystem.
Obviously we're talking about using it as the default display server, and to that end they are and will. X will stay around for compatibility for quite a while of course.
> so in that sense they won't "go back".
No, so they won't switch to some other Xorg system, they'll just keep using what they have.
> Void is already working on packaging Xenocara and I doubt they'll be the last one; OpenBSD will just become the team that provides both a display server and a secure remote shell for lots of the Linux ecosystem.
I'm not sure about every last esoteric Linux distro, but the big ones. To that end, they are the ones actually paying people to develop Xorg and have been for many years. I don't see why they would move to something else even if they did go back to X, which they won't.
Feel free to set up a fund and sponsor X11 maintenance - there is surely a price where people will start working on it.
Most Linux graphics development is not unpaid.
As if it ever worked properly on X. I’m sure every professional used linux for tasks requiring color accuracy.
The problem is that it's "works on my machine" on both sides of the debate. Elsewhere in the comments is someone saying that they've never seen screen tearing and have perfectly good HiDPI on X.
I will make one statistical argument - Fedora is Wayland-by-default now. Plenty of people still use Fedora and have no problems.
To be honest I associate 'barely usable' more with X11. I haven't forgotten the good old days when I had to hack various configuration files just to get a working desktop and then hack some more to work around issues with tearing, video acceleration, etc.
Wayland on the other had has just worked right out of the box since Debian 11. I have not touched a single file, line or character to get Wayland to work optiminally. That is a remarkable achievement IMHO which X11 took years and years to achieve.