Wayland is an interesting beast. X11, for all its faults, does a lot for the desktop environment. If you’re stretched for time, you could – in theory – just slap a panel onto the default X11 window manager and call it a day. The modern landscape of desktop environments built on top of X11 exists because developers have gotten really good at eschewing X11’s built-in crusty junk for their own new and shiny junk, so that things work as you’d expect them to. For the most part, this kinda works – with enough hacks, you can get things like variable refresh rate, fractional scaling, et cetera.
The problem here is that X11 definitely was not built for those things. Variable refresh rate works, but only if you’re using a single monitor, and mixed refresh rate monitors in a single X session don’t work at all outside of the hardware cursor. Fractional scaling is a hack. Compositing in general is optional and is sort of just stapled onto the existing architecture. X11 does do what it needs to do, which is display windows, but it’s kinda garbo when you need it to do anything more advanced.
Wayland is what happens when issues with the dominant windowing protocol have been festering for decades. It throws away everything and establishes a core set of standards that must be adhered to, along with a (very large) set of extensions that can be optionally implemented. The website https://wayland.app/ shows all the protocols worth knowing, and a lot more on top of that. It’s kinda like Vulkan, in a sense: the core has the basics, and everything else is extensions that can be queried for by clients.
Wayland is such a massive improvement over X11 it absolutely boggles the mind that people try to claim otherwise. I’m glad we’re finally at a point where Wayland has clearly won, and developers are finally free to focus their efforts on the clearly superior choice, instead of wasting more time trying to hack X11 into the 21st century.
Sounds a lot like change to me. We can’t have that!!
Yeah, let’s throw out something that had worked well for the past decades in favor of something that is basically in alpha state, require every app to be basically rewritten in order to work with it (which big projects like Firefox can do and did, at the great expense, but good luck with small, often single-dev projects doing it), require basically new drivers for everything and can’t even do simple things like screen recording or global hotkeys without some nasty hacks such as pipewire to make it possible, where X11 has it all built-in and all that’s needed was a reimplementation of the X protocol without using any of the legacy X11 code. So basically X12.
Change is happening whether you like it or not. The beauty here is that you can keep using that old outdated software. Better yet, you can devote unlimited amounts of your time & resources to making sure it still works for the next future decades.
What we have lost is the remote rendering of X11 – and that’s probably OK. Being able to blend the output windows from multiple machines onto a single display was very useful, but it’s a different world now, with multiple paths to achieve the same results through different ways. Remote desktop is good and useful, but not exactly the same use-case – more of a virtual machine display than remote windows (lower-case W). And Wayland on the local machine today is necessary for modern displays and hardware; dragging all that X11 baggage along is too much.
I’m not biased towards X11 at all, I would have been ready to ditch it last decade and god knows X11 has a lot of baggage, but wayland is still incomplete in terms of functionality that I cannot do without, like remote desktop sharing, I find it extremely unfortunate that wayland devs have refused to implement screen sharing in a unified way. Now every compositor has to implement their own features separately. And until they do I have no choice but to keep using X11 or give up my preferred desktops.
While performance is less important for me, I actually benchmarked wayland versus X11 and surprisingly X11 actually won. While the X11 architecture is notoriously bloated, it’s code paths did seem to be better optimized using nvidia drivers and upgrading to wayland ironically leads to lower performance, This was last year, so things may have changed and different hardware may produce different results,, but for all the shade that wayland fans throw at X11 it’s just ironic that it has more features and higher performance for some of us.
“While the X11 architecture is notoriously bloated, it’s code paths did seem to be better optimized using nvidia drivers and upgrading to wayland ironically leads to lower performance,”
let’s assume this applies to anything new(er).
I’m willing to believe they’ll fix that.
I really do hope they complete the feature list people want.
“I’m willing to believe they’ll fix that.””
Every ‘”fix” they have attempted is some mega evil patch… just buy AMD or Intel hardware for PCs or some other open source driver supported GPU for mobile/embedded.
Part of the reason X11 has needed a true replacement is because of ” the remote rendering of X11″. X11 was written for a world that no longer exists, with large minicomputers and mainframes running the applications, but output done across relatively low bandwidth networks and rendered on pretty rudimentary terminals. Nowadays, the GUI and application are almost always rendered on the same machine, making the idea of “clients” and “servers” in X11 pretty much obsolete.
Of course, you can still do similar today, with Thin Clients and RDS. And you also have the “Cloud Computing” aspect, which is largely the same idea, but done completely differently. It’s not that we don’t have client and server models nowadays, it’s that the implementation and execution of them is almost entirely unrecognisable to those used 40-50 years ago. Technology moves on, and that’s something we have to learn to accept.
The remoteness feature of X11 was largely based on a remote drawing api (exposed to the developer as XLib) which passed over the network instructions such as “draw a square here” rather than passing the square bitmap data itself.
This was quite efficient for the low bandwidth and low graphical capabilities of the 80’s and 90’s, but this got pretty soon long in the tooth, as those drawing apis were pretty limited (want antialias? want accelerated 3d? want hardware accelerated video? bad luck)
So much so that all modern toolkits since the last ~15 years or so renounced using those basic drawing apis at all and moved to rendering their whole ui to images themselves and then pushing just the final raster images to the X server, effectively making the performance *horrible* on remote (and better on the local machine, also bypassing the whole network thing with extensions such as drm,damage,glx and what not when possible)
so much so that things like VNC de facto replaced the remote access parts of X.
Remote access is still much needed, but nowdays there are much better technologies. What needs to happen is server-side rendering on a GPU encoded video stream, the client consuming such video stream while sending input commands. This is what Microsoft RDP is doing, with a compatible server already there in Gnome and one in the works on KDE Plasma as well.
Both of which are Wayland-only, as is the job for the compositor itself to do it in a performant and low-latency enough fashion.
Probably more linux-centric protocols for this will also happen as well, but the base concept will still be a video encoding centric approach.
I have two issues with wayland. 1. Performance on amd/intel egpu setup and 2. Mate desktop support. Fix those and I’m happy to move. Heck just fork mutter and fix the inconsistencies with Marco and I’ll probably move tomorrow.
I’m with you on this. I’ve been waiting for Mate Desktop support. Without that I have no way to use Wayland. No switching to another desktop is not the answer. I may as well go back to Windows and hope I can scare up a working shell replacement after all these years or try to get OSX86 to run on my hardware if the “answer” is switching desktops. So I wait..
Is OSX86 still a thing? Eventually, most people involved realised that buying a refurb Mac is a better way to get OS X than trying to hack MacOS on a PC, leaving a small selection of die hards who aren’t enough to keep the OSX86 project moving forward.
It is, but it is a dying thing sooner than later due to Apple Silicon.
You basically have two different groups. Those who just like the idea of a cheaper Macbook with their existing hardware and those who deliberately build a box with compatibility in mind with the goal of more powerful hardware at lower costs. But it’s still a pain and a half to track down what hardware needs to be placated to run properly and dealing with all the hacks needed to maintain working hardware between updates.
But it beats the hell out of running Windows again….
I’ll just leave it https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 here and call it a day.
Comparing Wayland to Vulkan is beyond asinine: with graphics no one expects anything on the screen except what you really wanna show which is different for everyone.
With a desktop PC graphical server, there are truly massive expectations:
* Task panel
* Systray
* Drag and drop
* Global shortcuts
etc. etc. etc. Just check the bug report.
Failure to provide all of that results in things getting reimplemented again and again with a ton of bugs and wasted man hours as seen by KDE/KWin.
14 years after Wayland was released we have practically the only relatively bug-free and feature complete DE for it which is Gnome while KDE has been struggling, XFCE/Mate have nothing, tiny projects like IceWM have rejected Wayland completely because it’s a crazy amount of work to be done.
Since that thread has been locked, let me point out that tray icons broke free of their XEmbed dependency a while ago as part of making them properly compatible with alpha-blended panels. It’s a D-Bus API named StatusNotifierItem:
https://freedesktop.org/wiki/Specifications/StatusNotifierItem/
It’s just not as widely used as it should be because the dominant client library for using it on the GTK side is libappindicator, which Canonical designed to force the primary/left click action to be their Weird Unity decision to have a popup menu be the primary/left-click action instead of toggling the visibility of the main window, as KDE does with consumers of their unrestricted KStatusNotifierItem client library.
(Yes, every tray icon you see out of a KDE application since KDE 4.0 is using KStatusNotifierItem and you probably didn’t notice the difference, while it’s not uncommon for GTK applications like the deluge-gtk torrent client to have a checkbox in their settings to select whether to use libappindicator.)
Nothing X11-specific about the code to do it. The application says “I want to display a tray icon. Here’s the image.” over D-Bus, and the panel sends D-Bus notifications when it’s clicked on.
Also, yes, I felt strongly enough about that to go through the hassle of clicking “Cancel” on Firefox’s “Choose a handler for chrome extension links” popup on the U2F/WebAuthn screen, and then digging out my TOTP authenticator. That one bug is the big reason I basically never log into OSAlert anymore.
None of those features that you mention have any place in a window server. They should be regular clients instead.
IMO X11 definitely needs replacement, but Wayland isn’t a good replacement. It brings with it some very significant issues that X11 didn’t have.
One is that there are multiple desktop-specific servers that implement a lot of DE functionality in the server at the lowest level. There’s absolutely no good reason why you can’t have one good policy-free compositor that does nothing but get pixels on screen. A compositing window server shouldn’t mean you have to drag in a whole bunch of attack surface and potential crashes that come with high-level desktop features. Literally the only thing that I can see desktop-specific servers making slightly easier are stupid useless bling effects like wobbly windows. Those absolutely are not worth compromising security and stability over.
Another very serious issue is the extreme architectural authoritarianism of leaving out APIs for accessing global state because they might be possible for malware to abuse. There’s absolutely no good reason why they can’t just be gated behind some kind of permission system. Of course, since global state APIs are a necessity for stuff like screen sharing, many Wayland servers implement them anyway through custom protocols on the side, leading to those kind of things being desktop-specific. To be fair, using sockets and anonymous shared memory makes security more difficult than something like user-mode filesystems where you can just separate out the privileged APIs into their own files.
It almost seems to me like Wayland was designed to make life more difficult for alternative desktops by forcing them to implement their own window servers and custom protocols for privileged features in addition to all the stuff that a desktop usually includes. It’s almost like they want people to get frustrated with the inevitable issues that come with the alternatives and just go back to GNOME. At the very least, GNOME probably doesn’t care if things are a lot more difficult for alternative desktops.
For the OS I’m writing, I’m planning to write a custom window server that will fix both the issues of X11 and Wayland. It will have a policy-free compositor with a reparenting window manager layered on top of it. The window manager will be set up to intercept window management requests from regular clients, in order to completely prevent things like focus stealing. Since literally everything in my OS will be a file (even memory), intercepting window management requests will be as easy as just layering the window manager’s filesystem on top of the window server’s, and the privileged APIs will be split out into separate files to allow easy access control. I’m thinking of just taking a Wayland server, ripping out protocol- and desktop-specific functionality, and implementing my own protocol layer (not sure which server I’ll use; it will just be whichever ends up being easiest to separate out base compositing from everything else).
I assume it’s too much work to port Arcan to it instead? Arcan has an XWayland-esque client which layers Wayland support on top of its less restrictive native protocol and it also splits the policy-defining UI frontend out into a separate process, similar to the Server/WM split in X.org.
Please keep us posted!
What do you think of the approach taken in SerenityOS?
I agree with this comment from the issue:
“I think building libraries to help bringing up Wayland compositors is the way to go.”
Mutter and KWin developers disagree which makes this statement completely inconsequential.
Do you mean they don’t want to use a library ? That’s not a problem.
I’m just saying: their should be libraries to make it easier for people to make stuff without having to implement underlying things.
“Should be” doesn’t describe the status quo which further proves that this quote from the linked bug report/feature request is completely inconsequential.
We’ve had Wayland for 14 years and by this time “should” should have been reality, not wishes.
That also means Wayland’s uptake will continue to be extremely slow.
My only issue with Wayland is that it’s purely Linux focused, with no love for the BSDs. It works great on all my hardware that runs Linux and I prefer it to X11, but it is far from ready for daily use on any of the BSDs. Arcan is coming along as a BSD focused alternative to X11, but it’s even less usable right now.
Um, what?
https://docs.freebsd.org/en/books/handbook/wayland/
Wayland on FreeBSD is the furthest along, but it’s in very early stages on NetBSD and OpenBSD so for the BSDs overall, it’s far behind Linux. For OpenBSD specifically, there are a lot of “Linuxisms” to overcome before it is on par with even the FreeBSD port.
Like systemd, Wayland is built on Linux, for Linux, with zero consideration for any other OS. All work towards porting it to the BSDs falls squarely on the BSD developers, and FreeBSD has by far the most developers out of the bunch so of course it is furthest along. It is, however, not ready for daily use yet unless you can deal with occasional breakage.
When Wayland first appeared their website stated that Wayland was only for Linux and didn’t target “fringe operating systems”. I mean Linux was fringe when X11 was ported and that’s Wayland in a nutshell.
There is also an initial port of Wayland to Haiku although it runs a bit differently than a normal wayland setup, as it runs the wayland server in the process of the client.
https://discuss.haiku-os.org/t/my-progress-in-wayland-compatibility-layer/12373/10
It can display most stuff that doesn’t require acceleration…and EGL is in the works.
Non-Wayland desktop environs with X11 are unusably slow. Before Wayland’s big 1000 cuts push on performance a few years ago, even it was almost unusable. X11 is too slow for even for basic stuff like terminal entry. It’s amazing to me that some people don’t even seem to notice that lag. Its not just for video, windowing, and games – even text entry on X11 is sluggish.
I’m glad Wayland is finally making this progress. I’m really just waiting for color/HDR management to ship, and then I can finally ditch Windows in every use case in my house. I’m SO ready for that.
I’m now running X.org on two of my devices and I notice neither sluggishness, nor lags.
What am I doing wrong?
And considering the whole Wayland motto is “perfect frames” if anything it’s affected by latency more than X.org. X.org doesn’t care about complete frames, it pushes everything at all times.
CaptainN-,
This might be the case for some users on some hardware, but obviously it’s not the case for everyone. It leads me to wonder if perhaps those experiencing performance problems are actually using the unaccellerated vesa drivers? Those drivers really are slow.
I think this may have more to do with your distro of choice than anything else. I have found X11 to be blazing fast on Void, Slackware, Pop!_OS, and OpenBSD, but noticeably slow on untweaked Debian, Fedora, some Slackware derivatives like Salix and Porteus, and recent Ubuntu releases.
Some of it may be hardware as well; even though Raspberry Pi OS is aggressively optimized for the hardware, X11 is still laggy as hell even on the RPi4/400/CM4. I have an ancient HP Stream netbook in my collection that on paper is not quite as fast as the RPi4, but even the laggiest AMD64 distro on that machine runs circles around any of the Pi OSes on their native hardware.
If your terminal input is slow… Maybe the problem is that you’re running an early 90s setup at this point in the XXI century?
I run Xorg just fine on a Pentium 233mhz over here, so i am guessing you have it configured wrong.
Some context from recent experience. I am a twitch gamer at heart – faster the responsiveness the better for me. I can notice a few milliseconds of difference. Others don’t seem bothered by the delay in input to screen.
I was running this on a Yoga 730 15″ (the one with nVidia 1050 GTX) – and a co-worker was running the same thing. He didn’t notice the laggy input, but I could actually see how slow it was on his machine. Some people are fine with it – I’m not. For me, it’s unusably slow compared with Windows (fast) or macOS (has more of an input delay from buffering than Windows or Wayland, but it’s not as slow as xorg was on Yoga 730).
To be clear, the problem comes when you do enable the GPU/HA pipelines (I think it was DRI, been a while since I played with it) and vsync (another whole problem that I even forgot about – tearing in the DE is unacceptable in 2023). It’s actually faster in xorg for things like text input if you don’t configure all that, and I suspect if you are using a 90s machine with quick text responses, you haven’t configured it.
It’s also possible I’m remembering a particularly problematic nVidia issue, or something specific to Optimus or this laptop – it’s been while since I ran on this machine – before nVidia’s supposed improvements to support Wayland/Linux DEs better. Either way, it was noticeably (for me) better with Wayland enabled and properly configured, on both Intel and nVidia, even for text input.
CaptainN–,
It is plausible that waylay was noticeably better with your hardware/software combination. I’ve also noticed that performance can be bad enough to be self evident in some cases, raspberry pi is an example. But when it comes to such subtle differences as a few ms, ideally tests should be conducted with blind A-B testing to eliminate the possibility of physiological biases where we can subconsciously project our expectations onto the result.
I just find it ironic that while some people are claiming X performance is bad for them, on my own hardware X was empirically faster than wayland. So clearly the “wayland is faster and X is laggy” isn’t factually true across the board. I have to concede my own test could be a statistical outlier…. it would be so interesting to see empirical numbers across hardware/drivers/distros/window managers/etc, but I’m not aware of anyone having done this and published results.
There’s other stuff too – in particular, on nVidia (I mostly ran Linux with nVidia disabled, since I wasn’t using that machine for gaming), everything was noticeably slower when it was enabled compared with Intel, but still not as slow as using xorg. Also, tearing was a real problem in Wayland for most apps using Xwayland. But also, when I properly enabled wayland support in big apps like Firefox – it was not a little faster, it was night and day faster. Even my co-worker could see the difference in those cases.
On games – I do recall it being a lot easier to run games in xorg, fwiw (again, a few years ago). There are plenty of benchmarks for these things for games out there – they all show a net advantage for Wayland in 2023 (at least on AMD…)
CaptainN–,
Well it certainly going to depend on what drivers you are using and from your description it sounds like you may have been using the unaccellerated vesa drivers. These drivers have very good compatibility and some distros use them by default. It’s kind of similar to running windows using standard vga drivers without acceleration, it works well enough to get the system up and running but hardware acceleration matters a great deal to performance.
It was Pop!_OS – and I’m sure everything was accelerated, I did check multiple times. Unaccelerated desktop environments at 4k (the Yoga 730 15’s default res) are painfully slow, not regular slow.
Come to think of it, it might have been noticeably slower because that screen is 4k, and I was running at 4k. Entirely possible xorg simply doesn’t (or didn’t) scale as well as Wayland.
Huh? I can set different refresh rates on my 3 monitors.
Interestingly, touch screen input on wayland does not bring up the onscreen keyboard in Firefox. Works fine in Xorg.
Some years ago, before Wayland, X’s solution was replace Xlib with XCB but it wasn’t widely adopted. Qt didn’t use it directly until 2-3 years ago.
The biggest problem about this statement is that it’s a blatant lie. If Wayland was good, we wouldn’t be arguing about it all the time.
What was the last time you saw people arguing about PipeWire? Never? Right, because it’s just fucking works.
Wayland so far has worked only for selected Gnome users.
Wayland is OKish until the compositor crashes or freezes, effectively killing open apps. I have had this pretty often with the current KDE after display wakeups. That was unacceptable, so I switched back to Xorg and it feels like an IMPROVEMENT: no issues with desktop sharing in certain apps, the global menu works with GTK+ apps, no more random freezes, when the compositor crashes, the apps persist because they are connected to Xorg, so no problem – the compositor is automatically restarted and back to normal. Performance-wise: it still feels snappy and tear-free, An no, my problems are not related to Nvidia or closed-source drivers, I have an Intel GPU now, with open-source drivers. The only relatively complete Wayland compositor with a ‘full’ desktop environment I have found is Gnome. I prefer KDE, however. Maybe KDE Plasma 6 (KWin is to be redesigned to survive crashes) will finally implement Wayland (and the Wayland protocol itself closes lingering gaps) to the point it will be at the very least on par with the Xorg implementation. There is another problem with Wayland, though: the protocol is limited by itself, meaning even some basic/common functionality has to be implemented OUTSIDE of Wayland, via ‘desktop portals’. That leads to an increased fragmentation, because, for instance, the developer of wlroots has different opinions on desktop sharing than, say, KDE or Gnome. Many people stick to Xorg not because they have reactionary/conservative mindset that dislikes ‘progress’, but because of still unresolved, genuine issues with Wayland.
Things aren’t good or bad if we strongly proclaim them to be so – how well they work determine that.
Furthermore, outrage is not an argument. Outrage is a rhetoric device to set up a moral panic.
Are there serious problems with Wayland? Well, I think there are. The decision not to implement a server (so having gnome, kde and other desktop environments reimplement the same thing) is really bad, IMO (no other popular desktop environment does this, AFAICT).
Bad software generally one can fix, bad architecture is much much harder. Does X11 have a bad architecture? Yes. The problem is that Wayland made a significantly bad architectural decision as well.
Wayland works great now if you use AMD GPUs. Most all the issues right now are due to Nvidia.
There are two excellent tiling window managers available in sway, hyprland, qtile, and lots more under development.
And there is also KDE, Gnome, and soon to be XFCE.
Its getting to the point it is more than usable for most anyone.
Is anyone testing wayland with eGPUs? best I can tell Wayland runs really badly on my 5700XT and it is probably trying to engage my builtin Intel GPU to handle everything.
In a way Wayland is a success story. Up to a point it was accepted by industry, still not by any major mobile platform like Android. As this was more or less on why it was created. Decision was made Xorg is not all that suitable for modern commercial mobile devices. And better to start from scratch then to fix Xorg. On the other hand Wayland is a failure. After a decade and a half still lacking in feature parity to Xorg. To the extent “fallback” mode to Xorg still being a common necessity. Things frequently not working and an advice to try the “fallback” mode usually accepted as a solution. The amount of fragmentation and work invested into migrating FOSS ecosystem to Wayland. That is just insane. Wayland causing a wasted decade in regards to dedicating sparse resources to other areas. It just eats up majority of resources if decision to migrate to Wayland is made. For years. So maybe in a couple of years, when we get to there, looking back one could say it was worth it. But then it will be 20 years old and likely something new will be made to replace it.
I’m sitting here this fine Sunday morning reading this article on my Kubuntu 23.04 machine running 3 monitors at 2560×1440 with a 120Hz refresh and compositing enabled on an older nVidia card using X.org. As I sipped my coffee I decided it’s been too long since I gave Wayland a look. Last time I did that things were seriously wonky.
I logged out and adjusted my login to use Wayland. First thing out of the gate I noticed it some of the default panels took longer than usual to load up. Normally they’re just there the moment the desktop starts. Not a big deal. I then started up a bunch of my usual apps. Everything looked about normal, though it seemed things may not have been quite as snappy. I got to thinking I may stick with this for a while and try it out. Then I heard something I don’t normally hear… my PC’s fans. CPU activity was cranking up. Having a look, it was the Plasma libraries trying to do something with Wayland.
Switching back to X.org, everything is back to being snappy and responsive. Fans were back to barely audible. I think I’ll be sticking with X.org for the next couple of years while folks work on Wayland to see where it’s at then. No, I don’t care if the Plasma libs are at fault or not. I’m an end user who just wants it to work.
Interesting contrast. I remember back when X.org forked X11 to clean up the code and become more responsive to end user needs. In about a year or 2 most every distro had switched over to X.org. From a purely end-user perspective, X.org was, and still is, an amazing success. I haven’t touched an X11 config file in years now, and I’m playing AAA titles via Steam. All the while, I can still muddle around with any window manager, or forward my desktop session to my laptop.
Seriously, for us end users, it’s been a LONG time since all the promises of Wayland. All the while, X.org has been pretty awesome for me. After 14 years (Wikipedia entry: Sep 30 2008) it’s nice to see it achieve “pretty good” status. What’s really funny are the folks here talking about how old X11 is, and the new Wayland is here to take over. Sorry to say, but Wayland is getting pretty long in the tooth there as well. Might be time to replace it with something newer.