There are many applications out there that use more than one window, with every modern-day platform and GUI toolkit offering the means for said application to position each of its windows exactly where it wants, and to restore these exactly in the configuration and location where the user saved it for that particular session. All toolkits but one, that is, for the Wayland project keeps shooting down proposals. Most recently merge request #264 for the ext-zones protocol by [Matthias Klumpp] as it descended into a 600+ comments spree.
This follows on an attempt two years prior with MR#247, which was rejected despite laying out sound reasons why the session protocol of Wayland does not cover many situations. In the breakdown video of the new ext-zones protocol discussion by [Brodie Robertson] the sheer absurdity of this whole situation becomes apparent, especially since KDE and others are already working around the Wayland project with their own extensions such as via KWin, which is being used commercially in e.g. the automotive world.
In a January 2024 blog post [Matthias] lays out many of his reasonings and views regarding the topic, with a focus on Linux desktop application usage from a scientific application perspective. When porting a Windows-, X11- or MacOS application to Wayland runs into compatibility issues that may necessitate a complete rewrite or dropping of features, the developer is more likely to stick to X11, to not port to Linux at all, or to use what eventually will amount to Wayland forks that patch around these missing API features.
Meanwhile X11 is definitely getting very long in the tooth, yet without it being a clean drop-in replacement it leaves many developers and end-users less than impressed. Perhaps the Wayland project should focus more on the needs of developers and end-users, and less about what it deems to be the One True Way?
Yes. Wayland is a great rewrite, but part of its governance is a few knuckleheads that bike-shed the dumbest stuff.
[[citation needed]]
I’m having Gnome 3 flashbacks.
Wayland is simply not usable for serious work: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/
90% of those complaints are just restating “window positioning”, and the other 10% is “bugs in our/their code”.
I’ve been using Kicad under wayland without major issue for a couple of years now. I can live with minor annoyances, because X11 isn’t pain-free either. “Not usable for serious work” is complete bollocks – and people have been saying the same thing about Kicad around these parts for longer than wayland has been around. Was just as rubbish a take there.
Some of the mentioned features are working just fine on native Wayland. Unfortunately the official builds disable Wayland support and so suffer from all the translation bugs coming from XWayland too.
I immediately switch to X11 since one of my must-have applications does not support Wayland and probably never will. It’s Barrier, the software KVM that I use on the three systems on my desk (Two Linux, one Windows). I looked into Wayland friendly substitutes a year or so ago, and there was nothing ready for Prime Time. Hopefully that will change.
Try rkvm ( https://github.com/htrefil/rkvm ). It simply forwards low level keyboard / mouse events from evdev, and doesn’t really depend on x11 or wayland at all. In fact, It works with text mode consoles as well.
The advantage of Barrier is you don’t have to hit a keyboard shortcut; you just tell it where the other computer’s screen is physically in relation to your main screen, and then simply move the mouse over like moving it to another screen on the same machine. It’s completely seamless.
InputLeap is a Wayland compatible fork of Barrier. I’ve been using it for the last six months or so without issue. I still have Barrier installed on my Windows work laptop, just had to copy my keys over and it just worked (I was previously using Barrier on Windows 10 and also X11 under Arch). Only complaint is that KInputWrapper requests input control anytime my monitor configuration changes or the computer wakes from sleep, but it’s a mild annoyance.
The only feature missing (for me at least) is the clipboard. To get around that, I just use copyq with directory syncing. I’m sure there’s other projects out there that are better, but considering I can’t be an administrator on my work laptop, it works well enough.
I’ve been using deskflow with wayland, and it works pretty well. also fixes some of the bugs in barrier, it being actually maintained. ( the forks / development timeline on synergy/barrier/deskflow is very weird )
Synergy added Wayland support about half a year ago, might be worth checking it out if you haven’t tried it recently.
Deskflow is the solution. It’s even compatible with barrier.
I’m pretty sure the Barrier project has been abandoned. There are several forks, such as inputleap.
I tried Wayland for about an hour, ran into multiple complete showstopper incompatibilities. Started out assuming it must be my misconfiguration, quickly discovered all were well known and things the developers refuse to address, and have no workarounds, and switched back to x11.
I don’t care how much newer Wayland is, it it doesn’t allow me to do the basic things I need to do, it’s a complete non-starter.
Similarity, I don’t care how old x11 is, if it makes my life easy and just works, I’m going to keep using it.
Oh wow, an hour! You poor thing, so much of your life wasted.
If you read the comment you are responding to carefully, you might notice that the amount of time they spent using Wayland was not, in fact, the complaint.
The “just works” is not that great with X11 either. Color management on X11 was a hack. Using two displays with different DPI or different refresh frequency at the same time almost impossible.
Both solutions have their age related issues.. X11 is too old nowadays (nobody uses the X11 primitives, all frameworks just send pixbufs around). Wayland is too young and the security angle (that X11 never bothered with) is making life hard for apps.
Oh that’s a complete lie, I use X11 and I have 3 completely different monitors. One is 1440p@180hz, one is 1200p@75hz and one is 1080p@60hz and they all work together just fine. And yes each one is set and running at it’s native resolution and frequency.
But are they all different DPIs, and do they also use different fractional scaling factors, and does the cursor and apps look “normal” as you move them between monitors?
“security angle (that X11 never bothered with)”
X11 has had very strong and fine-grained security since X Access Control Extension (XACE) was added in 2008. This includes system-enforced policy for all properties, calls, etc. (This even includes things like automatic redaction of screenshots!)
Wayland, on the other hand, is impossible to secure in any meaningful manner. This is due to architectural issues and isn’t something that can be fixed by adding another portal or the like; implementing meaningful security would require a complete [and incompatible] redesign of Wayland’s architecture.
I use the drawing primitives. They are quicker then pushing around pixbufs, especially with remote X.
Completely agree. It is a painful experience. It is being forced on us, in a way that is identical to all the things we complain about Microsoft. It is a mess with a long list of usability incompatibilities, and run by people who are showing some traits of bullying,
Remind me the problem Wayland is trying to solve? New for the sake of new is not a solution, its a problem of it’s own making.
See also systemd…
Ok, the basic idea about the sysV init system being no longer really fit for purpose is basically correct. But why the bloody init system should do all things, network management, home directories, etc. is not clear to me.(plus I have had problems with the software coming from that specific author for a long time).
I’m going to assume that’s an honest question, despite strongly feeling it isn’t.
The init system don’t network management and hinge directories is because in the general case, both are complex and tightly integrated with system being up.
If your home directory is just a directory in the root filesystem, then great, there’s no work for anything to do. If it’s an encrypted network mount then you somehow now need to tie in network startup (potentially multiple networks) and user login. Something needs to orchestrate these bits in an orderly manner to support the use case and the pre-systemd options were all pretty terrible.
Systemd might not be perfect, but it enables things that were impossible to do in a standard way before.
Also, a lot of the stuff people complain about systemd doing being out of scope for an init system aren’t actually being done by the core systemd init system – systemd isn’t just an init system, it also includes a bunch of additional tools that plug into it in a consistent way, and networking, DNS, home folder management are all part of that toolkit of optional extras that work with systemd but aren’t an intrinsic part of it
Try disabling journald. Well you can’t.
It’s not really a justification, but I’ve grown to like the “global” journal, and systemd timers have completely replaced cron, to the point I don’t even have a cron installed anymore.
Wayland, on the other hand, hasn’t provided me with anything but headaches and bad performance.
systemd is a page out of the OS X / Android (and probably many others) playbooks. It’s an inevitable sort of step when you decide that a certain kind of seamlessness and control is more important than user configurability. I hate it intensely but it’s real obvious to me the problem they are trying to solve. There are things that logically should not be clustered together under one roof but which users expect a friendly OS to do invisibly and coherently, and systemd is aimed at that challenge. Instead of doing one thing well, systemd does a zillion vaguely-related tasks in a way that most users won’t object to.
Systemd is super configurable though, I’ve found it an order of magnitude easier to work with than whenever I was trying to get my head around startup tasks on older systems which tended to be a confusing mess of 2 or 3 different systems, managing systemd unit file is super easy with only a little bit of effort to learn them
i hear this claim often, and for a certain class of service i figure it must be true.
But my own experience is the opposite. The documentation is a lie and everything i wanted to do needed to interact with built-in undocumented implicit units created by hardcoded C code and not described in .service files. In addition i discovered documented-but-unsettable global flags which dramatically influenced the behavior. The root idiom of services/units simply isn’t sufficient to the tasks that the systemd authors wanted to conquer, and they freely hacked to connect the gaps.
And fwiw i have never had any trouble wrapping my head around startup tasks on older systems even as they have become a mess of 2 or 3 different systems. Every SYSV-init-derived system i’ve met has been absolutely transparent to me, because at the bottom it’s shell scripts and i know how to read and write shell scripts. IOW, learning how to read and write shell scripts made me an expert user of init, but learning how to read and write .service files was not sufficient to use systemd.
The kicker is, when i uninstalled systemd, i had problems fix themselves that i didn’t even realize were caused by systemd!
I also use X11 exclusively because Wayland is just bad, but one of the main problems it solves, which is laudable, is preventing shatter attacks and generally better ownership and security around access cross-application / windows.
Ok, so why not just improve X11?
I’d suggest you can’t ‘improve’ X11 on many core more security related features that Wayland does better without it becoming basically a complete rewrite – X11 was built in a very different time with different basic goal and that legacy is still the foundation of the codebase.
X11’s security issues were fixed with X Access Control Extension (XACE) back in 2008. That no DEs chose to implement a user-friendly configuration interface for it and that no distros chose to define default policies for it [which they did define at the filesystem level] is not the fault of X11.
It’s worth noting that due to intractable architectural issues Wayland cannot implement any meaningful security, never mind the fine-grained control that X11 allows.
In order to fix the issues with X11, the first thing you need to do is rewrite / redesign the protocol from scratch. The first serious attempt at that is Wayland
Xlibre is doing that.
Because the X11 maintainers have refused anything other than minor bug fixes for about 10 years now.
Hence the rise of XLibre…
But how many applications do you actually run containerized enough that they couldn’t attack each other through normal user privileges? Especially on a developer system, it’s not that rare to allow full ptrace/gdb access between user processes.
As soon as you have a process running with user permissions outside a sandbox, the attack surface is enormous. Can’t do a keylogger? Just replace the shortcut to your password manager or bitcoin wallet with a shortcut to a backdoored version.
Actually a lot. With atomic Fedora like Silverblue almost all my desktop apps are sandboxed Flatpaks.
“X11 is decrepit, unmaintainable, and will progressively slide into uselessness in the next decade or so.” Is that a sufficient problem to require a solution?
And no, “just suck it up and fix X11” isn’t on the table, unless you’re volunteering to do it.
Its amazing how people craft a bs argument then support it to try and shutdown conversation.
I can do it too:
“Wayland is decrepit, lacks feature parity with decades old software (x11), and due to this stance will progressively slide into uselessness in the next decade or so”
And no, apparently people literally writing the code that only has to be reviewed and merged into Wayland apparently “isn’t on the table”
I wasn’t crafting an argument, I was responding to the question “why does Wayland exist”. It’s not a claim to be rebutted, and it wasn’t BS. It’s Wayland’s mission statement.
Given that committing “code” (there’s no code, it’s a protocol specification) to Wayland has nothing to do with fixing X11, I can’t see why you’re bringing it up other than you’ve lost track of the conversation.
And that “protocol specification” is written in what, exactly? Poetry? Movie scripts?
Your ridiculous pedanticism, prejudiced response, and general ad hominems are all open to be rebutted, whether you like it or not.
That’s why xlibre was forked and is X11 with updates and bug fixes.
I mean see Ubuntu’s shoving of rust via sudo-rs.
No feature parity, slower, and now CVE’s! Mission Accomplished!
https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10
That’s not a problem with Rust though, Rust being memory safe doesn’t make it completely bug proof in all regards, that should be obvious from the fact that the original sudo bugs aren’t memory related (which by the way is part of what a rewrite would be aiming to fix, sudo has plenty of its own CVEs including the recent one where you could just feed it an attacker controlled sudoers file to gain sudo privileges)
since when this should be problem of Xserver (what ever implementation) ? why do we have window managers then?
Been using sway (Wayland replacement for i3-wm) for 5 years or more, and never had an issue that forced me going back to Xorg. The most notable problem I had was with KiCad freezing when bringing up some dialogs, and I worked around the problem by starting a Xephyr session inside sway just for KiCad stuff. And that was months ago, today KiCad is working great in sway without having to use Xephyr.
That said, I am not defending the stance of some Wayland devs that freeze implementation even of basic stuff. They should get their shit done, even if it’s not the best implementation in the world. Wayland has to advance if it wants to replace Xorg sooner than later.
As long as Wayland can’t even do basic stuff like opening an application in the same position and size as last time I used it, I’m not using it.
Wayland doesn’t “do” anything. It’s an agreement between app frameworks and desktop compositors. It takes time for those groups to agree on sane behavior that works everywhere, especially with multiple screens, phones/tablets/cars and/or desktop paradigms (e.g. tiling 1 or phone).
How would you deal with an application that tries to place it’s windows to global coordinates when you launch it on a large monitor, but it keeps running when you undock the phone and have just the small touch screen? How about when you change monitor virtual scale? Switch to tiled mode, unplug laptop from monitor, switch back..?
Do you enjoy what happens when you launch a game in Windows that switches your desktop to 640×480, then crashes? Windows apps are still allowed to do that, you know.
Anyway, Mutter (GNOME) already has session management protocol support, KWin (KDE) is almost there. Rest will follow eventually. So yeah, windows will eventually reopen where you left them.
But honestly, it’s not app’s business to open itself anywhere. I launch it and it will be placed by my compositor according to how I have configured it. It may be restored on launch, that’s fine, but it’s not deciding on its own where it goes.
https://blog.system76.com/post/cosmic-de-tiling-redesign-and-libcosmic-rebasing ↩
Sigh:
https://blog.system76.com/post/cosmic-de-tiling-redesign-and-libcosmic-rebasing
That’s indeed the design philosophy they are going with. The reality is that it was always awful for apps to control their own windowing for exactly the sorts of reasons you brought up examples for. People being used to that paradigm does not make the paradigm any less awful. Wayland isn’t trying to forcefully kill it. It’s just diametrically opposed to their uncompromising design goal. They refuse to make the compositor foundationally crappy at the behest of your crappy apps.
“Wayland doesn’t do anything”
Neither does X. X, like Wayland is “just a protocol”. It does take time for groups to agree. The X protocol spec had this sorted by 1987 with X version 11. Wayland hasn’t got this sorted in 17 years.
The thing is, X has worked on all of those things where you say it’s hard. Solutions are known. The X protocol ensures the window managers know about the window positioning requests. Window managers can choose to ignore, obey or modify the requests.
“But honestly, it’s not app’s business to open itself anywhere.”
Well fundamentally this is the problem. For some apps it is.
This unfortunately is the Wayland way: everything Wayland does supposedly better than Wayland is because Wayland is good. Everything bad or someone else’s fault. And then blame the users.
As of today, Wayland based interfaces are missing a very common, very old feature, other than some nonstandard hacks.
And it’s missing unfortunately for ideologically blinkered reasons from people who have a limited view of what software ought to do. There’s no technical problem here: the X11 PROTOCOL supports placement fine, and window managers are good at dealing with it.
There’s more out there than simply popping up a window at the place it was last closed.
I’ve been advocating for this for a long time. IMHO it is the window managers responsibility to remember where your app was last time it was open and put it there again. Under X applications needed to take care of this themselves – they could because they could reposition themselves, so developers added code to save and restore their position. That leads to some apps doing it and some not. With the DE handling it you’ll get consistency, but the Wayland compositors have not implemented this yet – it’s on their radar, even Gnome. One thing they need is apps to indicate some kind of ID, so their window position can be associated with that, and they’d also like to have some way to handle child windows.
I’m unfortunately being forced off GNOME after 25 years now Arch is only building the Wayland version (not a criticism, I am aware the X11 code will soon be gone), not because I have a philosophical problem with Wayland but I still seem to have all sorts of problems with it ranging from strange graphical glitches to unfortunately common complete crashes of the desktop.
I don’t have the same problems when running stuff inside X, and I don’t need anything that Wayland offers (better scaling, better control of different monitors etc.) but I do need to actually get some work done!
Those are the biggest myths about Wayland’s pros, X11 can totally provides those.
HOWEVER, I’m not sure I could drive screens with different refresh rate on X11 but I don’t use it, I don’t even use my main screen beyond 60Hz while it is capable of 120Hz (and supported by X11), so both screen, no need of it.
Regarding “old code”, the Xlibre project – fork of IBM’s Xorg – seems quite vibrant.
Wayland is not even correctly working with GNOME (loss of cursor, un-focusable popup etc…), while it’s ok for a young/new projetct, we are 15year in, Wayland got full team support.
And without wlroots and now libhyperland, writing a WM/desktop needs to rewrite everything.
That seems more like a GNOME problem to me. No such issues on KDE and other competent Wayland WMs like Niri, Wayfire, LabWC etc.
I haven’t tried any of those other Wayland WMs, but KDE definitely has problems too. Don’t believe me? Try running KDE + Wayland with an Nvidia GPU. Try firing up Steam and see what happens. All very well documented (and completely unresolved) problems that make Wayland a nonstarter for 50+% of PC users. Maybe it is, as you and others try pointing out, that “it’s the apps fault, not Wayland!” But from where I stand, looking at Wayland compared to my fully working X11 system, it seems like it might not be the app dev’s responsibility to accommodate a full redesign for a system that has hardly proven its value.
Looks like Windows is 30years ahead of Linux, again..
Do you mean that being a bunch of useless garbage only it’s main dev would defend is progress?
In what way is windows ahead? They can’t even figure out where to put settings? They aren’t anywhere near from thinking about windows positioning.
Btw about windows positioning w11 approach is currently to start with all opened windows collapsed what a fix.
I would very happily see Wayland dead and buried never to raise it’s ugly head again
I am using more than one year wayland with Sway compositor and it is pretty fast and simple to setup. I have no reason to come back into old monolitic unsecure x11. Remmina client with vnc is working without any issue in wayland. And all web based applications too. The streaming from my Sunshine server with Moonlight client for Waylant is super.
Linux on the desktop is so fragmented and the fight between desktops DE like KDE and Gnome just add to the mess. Not to mention the X11 vs Wayland that just never seems to get settled. I finally went back to Windows not because its that much better, I dislike Windows 11 a lot too. But I dislike Linux right now even more. After using Fedora for a few months, its clear to me Gnome developers are too obsessed with their philosophy of its alternative design point of view.
There isn’t a “fight” between any of those things you’ve mentioned. The only fights that happen are between overly attached users.
Wayland should not have been pushed forward until it replaced all X11 functions. Thank you KDE for working around this kludge.
Wayland fix your code.
You don’t improve software by keeping it in a lab and letting no users near it.
I love Wayland. I use wlroots with labwc and it’s extremely lightweight and fast. I see it as the future, though I do miss things like x11 forwarding and sensible screen sharing utilities. Surely there are amazing x11 apps that should continue to exist, but x11 has been around so long that there are some relics out there that were in need of a UI rewrite anyway.
SSH forwarding works. Either via XWayland (and ssh -X) or natively using waypipe.
Wait, you can’t do stuff which was easily doable back in Windows 95 using WinAPI?
2026 definitely year of Linux desktop XD
Wayland is such a joke. We’re all supposed to immediately drop X11 like it’s a cobalt source and jump on this brand new, shiny, new replacement– did we mention it’s new? Because X11 is old.
But still, a decade plus later, Wayland is missing basic functionality that every other window manager has had for half a century.
At this point Wayland itself is really old. Far older than most software the “new and shiny” type want to use. And it still is not basically functional for most uses.
How much longer until we all admit how incredibly absurd this whole situation is and move onto a window manager that actually works? Maybe one that hasn’t been stagnating for 15 years?
Fully agree. People do this same thing with hardware “but its old”….ok and? My most used laptop has an Intel Core M 5Y70 and was released in 2014… Compiling one of my projects on it takes ~12 min, on my Ryzen 9 6900hx the same project takes ~7 minutes.
Its still very usable for me and I certainly understand the desire for “better” with certain workloads, but for a majority of people the hardware is not a limitation. Phones are a perfect example of the “its too old” absurdity.
“It’s old” means it’s run through its initial momentum where most of the development happens, as it happens with most FOSS projects it seems. People who expect things to change much, or argue that it’ll become much better, will be disappointed because nothing much will happen in the “long tail” phase.
About 80% of the project will be done in the initial push when all the buzz is happening and then developer interest will wind down, because new developers find it difficult to get on top of what’s already been done, and the old developers are directing their attention at defending their work and views from being changed by the newcomers, and maintaining the project organization. The old developers find other more interesting projects to work on and just sit on top of this one, preventing anyone else from improving it without forking an entirely new copy, so the last 20% happens gradually over the years as small improvements and additions manage to slip by and get approved.
20 years later it’s going to be much the same as it was when 5 years old unless someone entirely different takes over. If the feature you wanted wasn’t in the initial 80% because it didn’t fit the scope or the resources/interest the original developers had, it probably won’t be in the last 20% either. That’s why, when people say “It’s old”, what they mean is “it’s not getting any better, let’s look elsewhere”.
What’s absurd is to take a cat for a dog and expect it to sneeze. Wayland is not a window manager. It’s a graphical server. If your window doesn’t restore to the place you’ve closed them, blame your window manager (Kwin or GDM or whatever you’re using). The issue in the article is when the application itself wants to create a new window and wants to position it, the lack of a protocol to do so (which protocol should be implemented by your WM). There’s nothing waylandesque here, it’s how you have many parties not agreeing on the same protocol.
Notice that you’ve the same issue with applications menu (somehow, Gnome dev decided that menu in GTK4 and later shouldn’t be published anymore, thus breaking the users with a global menu bar, à la Mac OS). KDE proposed a protocol for it, but since GDM dev don’t implement it, it doesn’t work for GTK4 apps on KDE. You can’t force a donkey to drink if it’s not thirsty.
GTK4 is a joke all round. Yes, there are some appealing performance boosts but from a developer’s point of view the sheer scale and wilfulness of the API changes (and zero assurance that GTK4 to 5 won’t be just as bad when the time comes) mean I’m genuinely more likely to migrate my project from GTK3 to Qt than I am to GTK4.
Having ported apps from Qt4 to Qt5, and Qt5 to Qt6, that’s not entirely painless either. It’s just the nature of major version number changes.
Which is probably why they want Wayland to implement it, so they wouldn’t have to care what the different WMs are doing or not doing.
Wayland is not a graphical server either. Wayland is a repo full of protocol specifications. So you are right about the Window manager. But the Window manager needs an agreement on how the protocol should look like.
Wayland compositors are BOTH display server and window manager.
Which is EXACTLY why I hate it. With X I have the freedom to use, try any and every window/desktop manager and switch whenever I want while never losing core functionality like remote access.
With Wayland every WM developer either reinvents ALL the wheels or you don’t get them.
Maybe someday someone will create something that acts as a hardware abstraction layer to put underneath a Wayland compositor and implement remote access on that level. Until then Wayland is just functionality removed for zero gain to the user.
I still just want decent Remote access.
For single applications waypipe is cool… I wish there was a way to use it from Android though. And… I wish it came with audio support built in.
Is it any better than X over SSH? I haven’t really noticed.
How about a Wayland equivalent to VNC? As far as I can tell that only seems to exist when it is built into a Desktop/Window manager. That seems to be the Wayland way… build everything into the Window manager. I’m sure all the Gnome fans are fine with that. I like switching around and trying different environments. I really don’t want to be tied to just the big few Desktop environments where they have the extra developers available to add in remote support.
Maybe even if I could just run the Compositor itself over Wayland and have it show up in a Window. Preferably then it would treat me re-sizing that Window just like if I changed monitor resolution settings locally. And again… Audio support!
Currently I use xorgxrdp, or I think that’s what it is. Getting that to work at all was a b1tch. Too many conflicting directions on the internet and all the official site wants to talk about is the client! For the longest time that had no audio for me and nothing I tried would change that. An update about a year ago magically fixed that. Yay! But.. no matter how I messed with keymapings the < button does not work normally when coming from Android. WTF! Finally I figured out just a couple days ago (after more than a year of trying)… if I add the Ctrl modifier, Ctrl+Shift+, instead of just Shift+, I actually get the < character. Without control I just get > for both keys!
Ok, enough ranting. I don’t care if it is X, Wayland or something new. I just want decent remote access. Even Mickeysoft figured that out!!
But the attitude from the Wayland developers… If they don’t think a feature is important it’s not going to happen. No doubt if you want this window positioning thing with Wayland you will be SOL forever.
“And… I wish it came with audio support built in.” Yes, I know. IF, terminal side you have PulseAudio or PipeWire you CAN get audio via a complex sequence of commands that you have to type every time. Forget that if your terminal is Android. And is it possible with WSL maybe? I don’t know.
This is not even close to what I mean when I say “built in”. Maybe add a “-a” to your waypipe command and then audio just works or something like that. That’s what I mean when I say built in.
Remote access? Tried nomachine? Free download, easy setup, reliable, stable. Linux, OSX, Android, iOS, Windows. Been using over 10y
Every couple of years or so I try Nomachine. It’s been a while, probably time to do so again. I remember thinking last time that it had come a long way but there was still a reason I didn’t stick with it. I don’t remember what that was. I do remember my overall impression was that it is difficult to get running on distros they don’t explicitly support and rather slow once it is working.
But again… I do remember thinking it was much improved last time so maybe it’s time to check again.
The server edition only sort of worked on my brand new install of Pop!_OS COSMIC. I could connect, but had no remote control capability.
I installed it with the tarball on the grid website (should have be done the deb file), and now I can’t remove it. Multiple pleas for help on the forums have only resulted in terse “read the documentation” responses.
I’m not a huge fan at present.
The client works great installed as a to flatpak.
“How about a Wayland equivalent to VNC” – eh? VNC isn’t an X or a Wayland thing, and you can use VNC with Wayland as either server or client.
Sorry, you are right. I think I remember now reading that there is one Wayland compositor that implements a VNC server backend. What was that, Sway maybe?
But that also kind of illustrates another of my points. What happens when you don’t want to use Sway? (Or whatever compositor implements a VNC server)
All the other Linux VNC servers out there ARE the X-server. And that means you can run any Window or Desktop manager you want on top of them. If you use Wayland, come to like a specific Compositor locally, then want to use it remotely too… well F-you, the Wayland devs decided it shouldn’t work that way and your preference doesn’t matter.
But my main purpose of my first comment wasn’t just to rip on Wayland. Even with X IMOP Linux is lacking good remote access. It’s just in X, easy, simple remote Audio is the ONLY thing lacking. In Wayland it’s that and more. If someone came out with a Wayland solution that did EVERYTHING I’d have no problems with dropping X.
Everything includes:
Ability to remote either a whole desktop/window manager with it’s child windows
Window/Desktop manager of the user’s choice
Ability to remote a single application w/o a window/desktop manager
Easy Audio – may be something that has to be enabled but make it one simple switch
Multiple sessions at the same time, independant of the local display, independant audio for each too
Also the ability to mirror the local display. (Actually, why not the ability to mirror any session, local or otherwise?)
Clipboard sharing w/ client machine
Full featured cross-platform clients. (Linux, Windows and Android for me please but for others Mac and iOS should be supported too)
Nice but not necessary features:
Drag & Drop File copying between server/client
Local printers
I don’t care if a solution is implented in X, Wayland or something new. I’d drop X in a heartbeat if the alternative had this!
Is it a big ask? Except maybe for some of the multi-session stuff Windows has all this. Yes, even the WM thing. Alternative shells do exist for Windows and do work in RDP.
I consider feature parity w/ Windows to be the low bar, not the high bar. Linux had remote access years before it came baked into Windows. Networkability was something Unix owned and Linux inherited. What happened? Linux seems to have stagnated for years and now a new generation of devs don’t want to take development forward again, they want to take it backwards!
My own observation is that Wayland solves zero problems that I have, and creates new issues I don’t currently have, in most cases by design.
Simply put it’s a crippled replacement for X11. The only thing going for it is that it’s “new”.
I do see the desire to produce clean architecture, but as a user I can’t see putting up with a worse user experience just to have a theoretically cleaner back end.
At present it’s not a question of when I switch to Wayland — it’s still a question of “if”. I am holding out hope that something better will come along before X11 becomes non-viable.
After going through the video. I realize one major thing on this whole Wayland part. And that’s Wayland doesn’t want to do what every one else does, because it doesn’t work for certain specific cases.
This is stupid. For one simple reason, it’s ignoring that people develop cross platform applications. If I make a cross platform application I look for APIs that are the same on all platforms. If I can position absolute windows on Windows/Mac/X11 but not on Wayland, then I would do the same as KiCAD, say “Wayland bad” and ignore it.
Precisely. The zoo of different WMs all doing their own thing and not doing whatever the other is doing is a problem for software developers, so they want Wayland to act as a sort of standard base – so Wayland lifting its hands up and saying “Not our job!!” becomes a problem for all.
That I can agree with. There’s benefit to discarding cruft from 40 years of outdated UI ideas but when you’re creating a standard that needs to be everything to everybody, you can’t have a hyper-narrow idea of what that is. There has to be an acknowledgement that perfect is the enemy of good.
Unfortunately we appear to have some zealots in the specification committee who want all applications to be rewritten to hew to their ideal chosen UI scheme, when there are countless use cases that fall outside their experience or direct personal need. You can’t do that and also expect universal adoption, and we need a solution which can be universally adopted.
“They should implement a protocol because everyone else does it” seems like a particularly boneheaded justification for developing a set of core features for a fundamental part of an operating system. If the best argument you can come up with for doing something is “Well Windows does it!” then maybe we should put a pin in this and focus on the much more important feature of putting ads and spyware in every part of the window manager that we can
It’s not that “that OS does it” but “a huge number of applications have UX designed around having it”. The OS and the GUI layer exist only to support the applications that run under it. Some of the people with authority in Wayland’s organisation believe that Wayland should be the tail that wags the dog.
There’s certainly benefit in discarding lots of things that X11 did and aren’t a good idea anymore, but window positioning is definitely something that should be standardized, leaving it up to the user and their compositor of choice to decide whether it is implemented, rather than the standards committee making the blanket choice for everybody.
Honestly they just need to bite the bullet and take on the monumental task of writing an all new windowing system, it’s gonna suck until it doesn’t and then it will be pleasant to work with, it’s a huge undertaking but it’s gotta be done at some point x11 can’t live forever, it’s had a hell of a run to last as long as it has and it’s a testament to the original teams design principles, but the tech debt is real, and importantly it’s real enough that GPU manufacturers don’t dedicate significant enough manpower supporting it, we need something new and easy to work with whilst retaining some of the core principles of x11s stability. If I had the skills and the time I’d write a system, but unfortunately my experience is pretty much nil, and my schedule doesn’t afford me much free time. Though I would be interested in learning about the core principles at least well enough to get started, because personally I don’t like most libraries for dealing with windows, as there’s never really a clear way to implement certain things some abstraction make using GL a time consuming feat if it’s even feasible in the first place.
I’m curious what exactly you think Wayland is supposed to be if not a new windowing system
I don’t really understand this current problem, though it looks like (A) something i don’t personally care about, and (B) a consequence of Wayland’s failure to differentiate between display management and window management. That failure is why i’m personally avoiding Wayland, because i don’t want to pick a window manager that will be abandoned when someone decides its underlying compositor architecture is dumb. I don’t want to chose between support for my new video card and a window placement engine that i find tolerable. Just insane to me that Wayland would force that choice on users. But to people who distro hop as an alternative to learning how to configure their GUI, i imagine the Wayland approach doesn’t seem to have downsides.
I also don’t really understand the problems with X11 — they all fall under “something i don’t personally care about.” Since i don’t hardly play video games, and since i don’t hardly use multi-monitor, and don’t really care about color accuracy or whatever. Though i did recently buy a laptop that was so far out of whack that i use “xrandr –gamma 0.8:0.8:1.0” to make it palatable, so it feels like X11 has my back. But on the other hand i do sometimes run into things like “there’s no way to sync to refresh in X11” — is that true??? It seems like a big deal. So i want to acknowledge that there are real downsides to X11 and people are surely right to chafe against them.
But i don’t personally at all agree with “X11 is getting very long in the tooth”. X11 strikes me as mature, not enfeebled. When i started with xfree86 in the 1990s, it was hard to configure, it was hard to build, it was hard to modify, it was hard to write software for. Now, xorg is always easy to configure. It’s much easier to modify than it was…I think some core Wayland developers are actually responsible for it, but the whole thing has been cut up into modules that you can build separately without pulling in some giant painful build process. All of the experimental “does this X server support ___?” sort of questions are now answered in the affirmative — xorg supports nearly every extension ever. And it actually has a huge advantage simply from standing still while computers move forward. It used to seem like downloading or building 10MB of source to get something done is a pain in the butt, but now it’s still only 10MB of source and i can download and build such a small codebase in no time. And the colllection of libraries that are available provides a lot of diversity as well, and they are all fairly mature now too. And on top of that, i’ve actually learned how to use it and i’ve gone from “only a voodoo wizard would use libX11 directly” to actually preferring xcb over libX11 but i’m comfortable in both.
If you’re basically living in the 90s (and you should be, nothing good has happened in computing since then, other than the enormous march of moore’s law in hardware), X11 is better than it’s ever been.
haha no sooner do i click submit than i realize i have to add on: git. git is the one good thing to happen since the 1990s :)
Wayland has had these issues all along. I’ve been using Linux since 1993, and Wayland started getting pushed by it’s fans around 2012. Every. Single. Feature. it didn’t support, you’d get ‘why would you want to do that?’, some boilerplate about X11 being obsolete (I would say it’s ‘mature’). It didn’t support multiple monitors initially (why would you want to do that?), no app forwarding (people said ‘why would you want to do that’ even after waypipe because they weren’t aware it existed…), ‘it doesn’t work on nvidia stuff’ (with a straight face they suggested dumping your GPU just ti run wayland instead of x11…)
Now it’s fairly feature complete, every thing above, and many many minor things, they’d say ‘why would you want to do that’ but then the devs would suck it up and implement it, or in a few cases where the main devs are so stubborn an extension was developed and de facto adopted by the wayland implementations (similar to how a bunch of junk in X is technically vendor extensions). My Ubuntu 22.04 systems are running x11 and AFAIK my 24.04 Wayland. I have no complaints.
Ive read some argument about this before, the wayland devs are convinced that since tiling window managers exist (and stuff in others that force windows to snap to a size and/or position), that an app being able to specify window size and positiin is ‘why would you want to do that?’. To me it’s ridiculous, those tiling window managers can ignore the window position stuff while everyone else uses it. But it’ll just be an extension, if kwin has one I imagine other wayland implementations will just adopt that one since the main wayland devs are convinced the wayland implementation (in x11 terms the window manager) should have exclusive control of window positioning.
The idea the application should position own window(s) on the screen comes from outdated principles of UI design for desktop systems. Tiling managers are one idea why that’s wrong, roaming between screens is another, and window management on mobiles devices next.
Who needs to remember window positioning if you have HDR?
Wayland should have been an experimental project never entering mainstream, but being a source of learning for future display servers that actually replace X11.
The current state of it is ridiculous.
Like most software projects… Never let the prototype go to waste ;) . Ha!
For me, Wayland Just Works. If I need a app window in a specific location, I’ll.use the dropdown menu, hit More , application settings. I need to put my daily driver apps in specific virtual windows. ..
This is just another example in a long long list of the “everything old is bad, replace it” cult doing their thing and as usual, their replacement for the old thing is new garbage.
Look at the recent sudo mess.
Look at ifconfig -> ip.
Wayland is just another example of bad code from a generation of coders that can’t even make UI elements that don’t jump scroll.
I’m tired of having to run away from these destroyers of everything to find things that they have ruined yet, only to have to do it again when they find your new haven. But I’m already contemplating firing up a VM and installing one of the BSD’s, just to see where they’re at.
Why can’t people just leave things alone.
ip output is just unreadable.
network device names are still so obsolete! Mine still isn’t even using half the characters on the keyboard!
If you want to stay on a corpse of a stack declared feature-frozen more than a decade ago, built on 1980s assumptions and is inherently unfixable… by all means. The rest of us will be getting work done. ;)
Turns out Mir was the answer all along.
:)
The article focuses on limitations encountered in mainstream floating desktop environments (GNOME, KDE), which depend directly on the semantics and constraints of core Wayland protocols — most notably the absence of standardized APIs for absolute window placement and multi-window session restoration.
These issues do not apply to Sway due to its fundamentally different architecture:
Sway exposes a full i3-compatible IPC interface, allowing external tools and scripts to control the compositor’s window tree directly, bypassing protocol-level restrictions imposed by upstream Wayland.
It intentionally does not adhere to the “applications must not manage windows” philosophy that GNOME and Mutter promote.
As a tiling compositor built on wlroots, Sway performs deterministic layout computation; window geometry is derived from the compositor’s internal tree, not from client-requested coordinates.
Users can reliably and predictably move, split, reattach, or migrate windows between outputs, because layout control is centralized in the compositor rather than delegated to applications.
Therefore, the majority of problems described in the article simply do not manifest in Wayland cimpositor like Sway, since tiling compositors avoid the entire class of window-positioning issues that affect floating desktop shells.
X11 Is Technically Obsolete
X11’s architecture is a historical accumulation of features dating back to 1984, resulting in a fragile and internally inconsistent system:
The monolithic X server implements rendering, input, window management, extensions, and protocol parsing in a single, tightly coupled process.
The protocol supports deep hierarchical window inheritance, legacy drawing primitives, synthetic events, and dozens of deprecated code paths that must remain for compatibility.
Security is fundamentally flawed: any X11 client can observe or inject input events for any other client because all clients share the same global event space.
The rendering model assumes outdated 2D hardware, relying on the XRender and core drawing APIs, while modern hardware requires compositing, which X11 added only as a layered extension.
The extension ecosystem (XInput2, XKB, RandR, Composite, DRI2/3, GLX, XFixes, etc.) forms a patchwork retrofit, not a coherent design.
Architectural constraints prevent removing legacy components without breaking existing applications, making meaningful modernization “architecturally impossible.”
Wayland and wlroots-based compositors exist because the X11 codebase and protocol design cannot be evolved into a modern system without destabilizing the entire stack. Replacing X11 proved easier and safer than attempting to repair or extend it.
Another reason Linux on the desktop will never become anything more than a gimmick
This was supposed to be a reply to the article as a whole, not your comment. Strange
Are you aware of the fact that apple did the same? Cocoa vs Quartz? And then change of platform from PPC to Intel and now to ARM.
The main difference is that Wayland has nowhere near the power to force the users to adapt.
Cool story. Now go rewrite it with a perspective that matters to someone who uses abilities that exist on X and do not exist on Wayland but do not even know of any that exist in Wayland but not X.
Wayland devs and wayland windows both need to be shown their place :)
I mean, if you want to stay on a stack that reads every keypress from every other client, captures all windows’ contents, injects synthetic input events, can move or resize other clients’ windows and cannot be fixed (because they’re not bugs (fixing these issues would quite literally break protocol compatibility and break core X11 mechanisms)… by all means, stay on X. Even their “security extension” has been deprecated for years because it’s incomplete, mostly unused and fundamentally incompatible with many parts of the protocol. There is absolutely NO path to secure X without destroying legacy compatibility, thus X will ALWAYS be broken, insecure and obsolete.
Further, X assumes the compositor is untrusted and that clients are trusted… which is the exact inverse of modern security requirements. The implication being that clients expect to draw directly onto shared buffers, the server/compositor must provide RAW access to global state, and there is absolutely no concept of sandboxed clients. You can’t “flip” X to a secure architecture without rewriting the protocol from scratch.
Even further, X’s rendering model is obsolete and unfixable. The core drawing API is implemented on the server, has been dead for 20 years, and has been removed from most GPU drivers (sans super-legacy stuff like EXA/UXA, and is incompatible with modern GPU pipelines. XRender/Composite/GLX patchwork have been “bolted on” over the decades, and are quite literally bodges. GLX is a hack — shared GL context living in the X server, Composite rewrites the entire pipeline into a software-composited model, and XRender is fixed-function stuck in the pre-OpenGL-2.0 era. X was built for network-transparent bitmap terminals, not GPU pipelines. This mismatch cannot be fixed without removing its essential architecture.
Worse, X’s input model is fundamentally unfixable for modern desktops: It cannot accurately represent touch/gesture states, it cannot express absolute coordinate devices reliably, it cannot express high-precision scroll/wheel deltas, it races input focus (two clients can believe they have it at the same time) and it delivers input to clients before the compositor knows about it, thus the compositor cannot reliably mediate input security OR routing. Again, this CANNOT be fixed without rewriting the entire input- and event-dispatch system (in other words, creating Wayland).
X’s window management is hacked together with “optional” extensions, essentially just a pile of afterthoughts, which makes it inconsistent, self-contradictory, and mutually incompatible especially in edge cases. No amount of patching can fix that which the core protocol didn’t anticipate: compositing, client-side decoration, variable refresh rates, multiple GPUs, multi-DPI/multi-scale, tear-free rendering, fractional scaling… all modern features that require bypassing most of X’s design.
X is frozen and cannot evolve. It was feature-frozen over a decade ago, so now only maintenance and fixes occur… no new features. The reasoning is that any major change risks breaking: thousands of legacy applications, embedded systems, remote X11 workflows (LOL), thin clients, and multi-decade toolkits. It simply WILL NOT gain modern features.
Sticking with X today is like insisting on running your entire modern workflow through a 386 with dialup: sure it technically works, but only through layers of hacks that fight against what the world actually looks like now. X was engineered for 1980s assumptions — trusted local apps, bitmap terminals, no compositing, no GPUs, no security boundaries — and every modern feature you use (hardware acceleration, tear-free output, multi-DPI monitors, sandboxed apps, gesture input, HDR, VRR) is bolted onto a corpse whose architecture quite literally cannot support them. There’s no sane reason to force desktops to rely on a system that was declared feature-dead over a decade ago. Wayland isn’t a fad, it’s simply what a display system looks like when it isn’t shackled to decisions made before the Internet as we know it existed.
I like your comparison to dial up. Whole Wayland architecture appeared in the first place to solve that f@#<|ng bottleneck.
If X11 is so bad then why is it supported longer than Qt, wxWidgets, XAML or even WinAPI?
It’s legacy but it gets the job done.
Does it, though?
Now post this in your own words and not copy pasted from ChatGPT
It’s not my fault you need a thesaurus to keep up. It’s interesting how you didn’t disprove anything I said — or provide a cogent rebuttal — just straight onto accusing me of using ChatGPT. You do you, I guess.
Its this kind of thing that totally kills Linux as a serious contender for desktop use. It needs to Just Work for every Linux program there is.
Aunty Joan isn’t going to understand that the program they are trying to run isn’t made for Wayland, she won’t care, all she knows is her program which is made for Linux doesn’t work.
The only way for Linux to actually make it to the desktop is to pick a single software stack and mandate it, if you don’t use the blessed stack you’re not Linux.
Honestly I believe that is already here in the form of Android. Google is pushing further into the desktop space and I believe they will crack it, all because they have the stones to say No, this is the API, Stack, and Services you MUST use.
So, when there is a proper Desktop installation of Android, Windows will continue to dominate.
But then instead of freedom of choice you simply have a Windows 2.0 but with backslashes in
cmd. It’s not what the community needs, and if normies cannot deal with ability to choose, they are free to kill themselves.Can anyone recommend a remote desktop application that works wel with Wayland ?
I tried several, VNC dialects, nomachine, but non of them seem to be stable.
I currently use Rustdesk, which seems to be the best I found, but it also presents problems and I regularly need to reconnect, and sometimes I need to connect a keyboard to the remote machine because it asks me to what display it has to connect, to the attached monitor, or to a square part of the screen.
Wayland is not bad. Its the maintainers who are making it bad & rejecting proposals. It is a known fact that a majority of the Wayland maintainers are Gnome devs, so yes….. that’s bound to happen.
Excellent article. And it’s obvious how many issues Wayland still has. Wayland is basically a trend right now. I say this because I use Arch with both X11 and Wayland. I disagree with the part where you say X11 is outdated — to this day it remains widely used on Linux and the BSDs. Besides, I’ve never had any problems with X11; it’s simple and straightforward, like just running startx.