KiCad and Wayland Support
kicad.org
kicad.org
We do not investigate or support bug reports related to Wayland-specific issues.
For now, if you need to use KiCad on Linux, use X11.
Can totally understand their position. I've developed cross-platform applications and it was enough work without the extra headache they describe Wayland brings.
I've been thinking about ditching Windows as my primary OS for some years, but Wayland has been really detrimental to the Linux desktop. Over a decade later and it's still not production ready, at least in my tests. Yet X11 is dying it seems, with GNOME and KDE dropping support soon[1][2].
From where I stand, the intentional fragmentation of the ecosystem seems like an especially poor decision.
[1]: https://www.omgubuntu.co.uk/2025/05/gnome-dropping-x11-suppo...
[2]: https://linuxiac.com/kde-x11-support-to-continue-until-plasm...
IMHO, Wayland will be dead before X11. There's too many things people want to do that Wayland designed out of their system. The future is likely a third system.
Probably something designed to service Win32 windowing APIs, because Win32 is basically the stable application toolkit, for better or worse.
Also see this thread where Vaxry lays out his gripes with Freedesktop.org: https://xcancel.com/vaxryy/status/1934721645115224431
Too bad Hyprland's community sucks
(And the winner appeared to be subversion, for a couple of years, and then git came along and won decisively -- with support for importing from subversion.)
I have been assuming that Wayland would pull itself together or else someone would build a competitor that does everything X11 can do, but also backwards and in heels and doing a creditable job at running X applications. Somehow neither of these has happened yet.
I am fond of the idea of arcan -- arcan-fe.com -- being that winner, but there doesn't seem to be much traction.
Wayland is indeed the subversion of window systems, can't wait for it to die and be replaced by a window system equivalent of git.
The X11 ecosystem might be very rich, but it's been 17 years since the Wayland project inception.
Just saying.
I fear the genetic code for such kind of work no longer exists in the DNA. Almost all new development work just doesn't have it in them at all.
Sometimes I wonder how this even happened, like, it seems impossible.
Then what XWayland is?
My thoughts exactly given the progress wine/proton is making; pretty much the only success story for Linux on the mainstream "desktop" (handheld) for over ten years. Though I'm not sure about the underlying infrastructure of SteamOS (Arch-based) and/or Bazzite (fedora-based); could well be Wayland raising its ugly head there, and I just don't see a new generation of developers or sponsors willing to invest into it.
Like when then went down into netbooks, first blow was the cheap Windows XP licenses, followed by tablets wiping the remaining ones, as OEMs found a better deal selling tablets, keyboards and covers than keeping netbooks arounds, while pivoting such designs into the expensive ultra-light laptops segment.
Microsoft only needs to use their weight as one of the biggest publishers in the market, one of the top three console vendors, and biggest gaming OS on desktop systems and game tournaments.
Also, fails to take into account that X has plenty of objective design failures, which is to be expected given GPUs didn't exist at the time of its invention.
Assuming that the entry https://en.wikipedia.org/wiki/X_Window_System is correct, the initial release was in 1984.
Amiga 500 Blitter, which is a baby step into GPU would become, is from 1987.
Texas Instruments TMS34010 was released in 1986, being the very first programmable graphics processor, going beyond DMA programable ones like the Amiga 500's Agnus.
https://en.wikipedia.org/wiki/TMS34010
While these jurassic GPUs could not be taken into account for X Window 1.0 design, by the time of X11R6 release, it was more than enough time to have had them into account.
EDIT: reformating
The first significant change was the ECS blitter much latter.
I spent some time last year digging around in Wayland and I've got to admit that I was surprised to learn that there really isn't anything really there. Like, there is no "system". I had read that "it's a protocol" but I hadn't fully internalized it. I'm honestly a bit surprised anyone has adopted it. It almost feels like a scam. :) When I checked you couldn't even get your window decorated without an extension (that Gnome decided to not support so you have to bring your own decorator there?).
They changed it so that everyone who previously just wrote a window manager now had to write an entire display server. The open source community just doesn't have that much manpower.
Not entirely true. Now if you want to share the "display server" bits you can plug in a library like wlroots or Smithay. The real issue, if any, is that most of those bits are not standardized; or at least, only the libwayland part.
Of course, that's not even the entire story either. When X11 servers were basically entire operating systems that ran as root, implemented print servers and directly touched /dev/mem, only a lunatic would want to maintain multiple of them... but now on Linux and even some BSDs, you can fall back to GBM/DRM/KMS/libinput/etc. for most of your "hardware" needs, the OS is doing the OS things. Wayland is also just simpler than X11; The current day cleaned-up X.org is still around 5x larger by SLOC and much more complex than wlroots.
So how come GNOME and KDE both built their own display server? Well really, they didn't; they took their existing compositors they had for X11 anyway and grew Wayland server limbs out of them. In practice retrofitting Wayland into existing compositors is still hard, but if you already have written a compositor and window manager it's still probably easier than writing a new one from scratch. And for KWin, I believe they're also making use of Qt's Wayland compositor infrastructure, too.
Something that took me a long time to understand is that people are just unhappy no matter what. Not that all of their points are invalid, just, it's often not even really about that; the specific points are often just the obvious weak spots, like the classic "Wayland can't screen capture" meme (totally fair point, but persisted so long that some people still don't know it hasn't been an issue for years.) This right here is just another one of those. Notice that when many Linux distros unified towards a singular init system, systemd, people came out with pitchforks. Were they all spouting incorrect nonsense? Well, blah blah UNIX philosophy, but largely no, there were plenty of valid complaints about systemd and what it meant for the Linux ecosystem, but it wasn't really about that. Same with Wayland! Wayland did the exact opposite, and defined a set of protocols anyone could implement, allowing you to choose your compositor. Seeing as people hated what systemd did and wanted to preserve "choice" in the Linux world, you'd expect that people would like what Wayland did, but instead everyone is just pissed about fragmentation now.
You can pick apart that argument and try to figure out why it's wrong or and invalid comparison and I'm not going to try to fight anyone on that. You can also say that the argument is made by different people and maybe that's true too (though personally I believe "people who hated systemd" and "people who hate Wayland" forms more of a circle than a venn diagram.) Even if it is, the outcome is the same: you're damned if you do and damned if you don't. What I do know is that desktops on X11 stagnated with the same sorts of problems they always had and with Wayland a lot of that got unblocked. X11 will probably be in the same crappy state it's in today and Wayland will continue iterating and improving over time. I'm sure there will be a lot of pain along the way, and I agree it isn't always pretty, but it is what it is. Software isn't a beauty contest, and there's a good reason why "elegant" stuff rarely wins in the long run.
As a mere Linux user, who's occasionally been annoyed at systemd and as mentioned have had poor experiences with Wayland implementations, I've been wondering about the alternate timeline where systemd and Wayland swapped approaches.
That is, systemd was just a set of protocols along with reference implementations, so people could say swap out journald to something that logged to text instead of a binary database etc.
And Wayland instead just did the whole kitchen sink, becoming the basis for the Linux desktop of the future, instead of fragmenting the existing ecosystem even more.
Probably a lot of good reasons why it wouldn't have been better, but it would be interesting to see what might have been.
Sure, there are similarities in the sense that you started out with 0 service files at the beginning and no GUI toolkit implemented the Wayland protocol from the start, but the thing itself is pretty different. Systemd wasn't designed by committee (and many people still have gripes about this). Wayland kinda is.
The magic is in finding what the right point in the abstraction is: what will be centralized and what will be decentralized. Both of your examples--systems and Wayland--made the same decision: the patchwork quilt of behaviors was complex for many users to get working, and even then often didn't work 100% always. It was also slow and a bit insecure (if you don't trust your software).
So, both systemd and Wayland took the same approach of pushing forward the boundary of abstraction and merging together most of the things people would have had to configure. This means that that one core component in the middle -- and sure: in Wayland you can have multiple implementations, and those can even share a library, but you can't MIX AND MATCH -- must do all of the things people want.
The reality is that no one wanted to maintain multiple X11 servers... but we also didn't want to! What we do want is to to be able to mix and match compositors and macro systems and window managers and all of the fun little behaviors that make a computer feel like it works for us, and now we can't, as we have to find and select a single giant ball of behaviors that happens to be close enough to what we wanted.
Theoretically, some day, someone could make a really advanced and capable display server for Wayland, one that will be extremely general and will have a number of protocols for how to extend its behavior. It will be the one display server to rule all display servers, and even ecosystems like Gnome and KDE could just interoperate with it, and we could get back the glorious ecosystem that people are killing...
...but that's effectively what X11 is, right now, and by the time you get that--with a ton of protocols that are old enough to be widely used--all of those behaviors will have aged and ossified and the code will be built by people who are gone in a language that isn't fun using conventions that are out of date, and some A-hole will point out that the stack is difficult to maintain and user's experience is variable and throw the entire thing out to start over :/.
Like, I dunno... I honestly do not understand how you are saying Wayland is doing the thing people wanted from systemd: the issue isn't that I wanted to be able to replace systemd, the issue is that I wanted systemd to not be a single giant C program because I really liked the patchwork of scripts and behaviors and alternative parts that were built up in the ecosystem.
And again: everything tends to end up with some central thing in the design somewhere... but you have to make that thing be so boring that no one has any interest in innovating on it, and X11 was that: while I do think we should have multiple implementations for robustness, we would expect every one of those implementations to work as close as possible to 100% identically.
I think whether Wayland really was what people wanted out of systemd or not is mostly not that important. I'm arguing that people were mad because systemd took away their choices, you're arguing that Wayland wasn't the choices they wanted. I'm not sure what choices they wanted. I don't think most people who are mad about new things have fully-formed opinions about what they actually want in the first place. Either way, Wayland gives you nothing if not plenty of choices, and many of them much more complete than what you could get with random WMs on X.
Most importantly, though, I strongly disagree that X11 is the ideal protocol to build on. X11 is a mess that's hard to implement and if you omit anything you'll basically always break a non-trivial amount of software. XInput 1 is pretty broken but tough, Wine needs it. Have fun implementing Xv everywhere too, and XRender. Most modern apps just grab a GL or Vulkan context and ignore all of that, but if you want to meaningfully implement X11 those things need to be there. I could go on, but I'm sure you get the point.
Realistically, I'm sure we don't want to maintain multiple X servers. As it is, nobody wants to really maintain X.org to begin with... Well, there is one guy, but that doesn't appear to have gone so well so far.
What's funny is, when people actually want to have X11 support, what they do instead is implement Wayland and use XWayland instead. Seriously, look at how many things implement Wayland: ChromeOS for Linux apps, SteamOS for game compositing, Windows for wslG, termux-x11... Wayland and Weston are much easier to implement and adapt than X11 and X.org were.
When everything works well across all of the GPU vendors and the major applications have the remaining kinks ironed out, things will keep moving along and the sky will probably not fall. I honestly think that people were going to get cranky even if everything was done absolutely perfectly here, because succeeding X requires some people to do a bunch of work and adjust their workflows. Don't blame 'em, doesn't mean they're right.
There are "Wayland display server toolkits" out there, so you can just build whatever you want without reimplementing a wheel. But an additional layer allowing for these plugins that X has is just added complexity that not every diplay server would want - e.g. a custom display server for a thermostat.
Application developers don't want to log your keyboard and aren't oblivious to security. The lack of a standard Wayland display server is a real grievance.
Would you swear that no "application" developer would want to log my keyboard if we include the transitive dependencies of every single nodejs/python/etc package that I use for regular-ass development? Because we have seen how trustworthy supply-chains are. But sure, you can definitely drive a car without a seatbelt on, it's just not a good idea.
It makes more sense to have an entirely different thing for embedded
The claim about OpenSource manpower is also false. We have multiple high quality compositors and despite any issues, there is quite a large amount of homebrew and other compositors.
If you want something like X11, you can built on something like Mir.
This is just a faulty sentence. If you meant that there is no general consensus on which extensions are "core core" and which are completely optional, that might be a more reasonable criticism.
Hence wlroots was born.
I feel you. I was there before and after Wayland. I was there when they promised you toward the promise land of the year of Linux Desktop and allegedly X11 is the main hurdle.
X11 is a proper system and protocol, and it seems the Wayland folks just ignore this. The two main reasons were given by them at the time were X11 has archaic architecture (reverse client and server concept) and, the X11 code is ancient and a mess. I'm kind of sold on their first idea of Linux need a clean windowing system so we can have something nice like RDP in Windows. But their second points on the codes debt is rather off. It did occur to me at the time it will be much easier to come up with a clean room implementation of X11 system and protocol rather than come up with entire new windowing system, than hope entire people and industries will use them. After all Linux basically is a clean room implementation of Unix.
I think the main problem is that at the time there's no authoritative figure like Linus on the non-kernel Linux part or what I called Linux user environment. At the time there was Miguel de Icaza of Gnome fame but at the time he seems too much involved with another promise land of Windows .Net and Linux people cannot come to term with the idea of we should just use Win32 as other comments have suggested here. It's proven later that .Net is an eventual failure as expected and Miguel reputation suffered because of that. Strangely to be honest I have never read Linus comment on Wayland but why would he? He's laser focus on the kernel and he's happy to admit using Fedora in the middle of the Red Hat Fedora bruhaha.
It's really not, it's designed for drawing on remote terminals over a network (it even has a print server), not hardware accelerated devices. Things like HDR, multiple refresh rates, mixed DPI, passive compositing, hardware planes are just harder to do.
There was a reason Android didn't use Xorg and instead used SurfaceFlinger (which shares more design with Wayland than Xorg).
IIRC SurfaceFlinger is tightly tied to Binder which is an Android only kernel IPC, didn't work with the standard Mesa stack and wasn't designed for multiple windows with multiple displays.
Wouldn't be surprised though if eventually Android swaps to Wayland as Google wants to merge it with ChromeOS. Since talking to the compositor is abstracted away to the platform APIs, I don't see it as big of a hurdle as X11 to Wayland was.
Though I would be happy if merging of work would happen in either direction.
Google sometimes tries to add these features (e.g. split screen, multiple windows etc) into the base code but can take time for OEMs to adopt them on their skins.
Are you sure it's easier to do with Wayland, all this while the Linux HDR is not working well [1],[2].
I've got the feeling that every features claimed to be easier with Wayland are all bogus and the same thing can be achieved with the same amount of effort and time on X. Wayland now really feel like the Emperor's New Cloth.
[1] Ubuntu 25.04 & Fedora 42 Hit A Long Sought Milestone With HDR Support Working Well On The Linux Desktop:
https://www.phoronix.com/review/linux-hdr-2025
[2] Wayland Color Management & HDR Protocol Support Merged:
Yes, but.
On a local machine the "network" is just system calls, and the kernel just hands the data from one process to the other. The overhead is minimal. HDR, multiple refresh rates, mixed DPI, these can all be implemented on the existing protocol. X11 actually closely resembles win32 (it was inspired by the same source after all - Xerox Parc GUI research), which has support for all of these things (it may not be pretty but are Adobe or the legion of game devs complaining? Of course not, it's write once and done.)
Yes, these things were designed out of Wayland, but that doesn't mean they shouldn't exist. It means the developers decided we probably shouldn't shove them into the display server. So we just put them somewhere else, and that seems to be working fine. The situation can only improve, truly.
In X11, I can still use all the same core features whether I run a full KDE desktop, Window Maker and a few dockapps, or a stack of xterms that I manually position with --geometry.
It does astonish me how Wayland missed obvious killer angles when they decided to reinvent X11. People would have been excited by "Here's a rich native toolkit so all the new software will look and work and theme consistently"-- a well-known and directly user-facing friction point, so how did they miss that?
> "Here's a rich native toolkit so all the new software will look and work and theme consistently"-- a well-known and directly user-facing friction point, so how did they miss that?
The problem is that application toolkits are a step above window managers and compositors. That's really an application developers choice, not a desktop's choice. Developers want to use Electron, and there's nothing we can do about that.
We can get consistently themed apps... if everyone hops on Qt. Which they won't because C++ is evil. People want to shove HTML and CSS into their music player and theme it like they do a website, so here we are.
This isn't a solved problem on any platform, even really really locked down ones like iOS. Half my iOS apps are web views which don't follow the look and feel of iOS and have inconsistent behavior as compared to the system. And iOS is the best about this honestly - it's, like, way worse on Windows which has half a dozen competing toolkits from Microsoft alone.
> The problem is that application toolkits are a step above window managers and compositors. That's really an application developers choice, not a desktop's choice. Developers want to use Electron, and there's nothing we can do about that.
OTOH most toolkits are themeable on global and application level. It is certainly possible for a working group to provide consistent themes for applications. E.g. my favorite theme is Adwaita dark[0] from ~Ubuntu 14, and it is possible to tell gtk/qt/tk/fltk/.. to look like this on a global level, and if some applications look bad due to icons or something, then fix them. It's just nobody is doing that.
And I agree, I don't see how could've been this a killer application for Wayland, this should be accomplished with distributing config files, and not somewhere near the display protocol.
[0] : https://www.google.com/search?q=ubuntu+adwaita+dark&udm=2
KDE today is still fairly themable if you stick to Qt apps and GTK 3 apps. But if you use a dozen frameworks then yeah, that's not themable anymore. Which really sucks but it is what it is. And, honestly, it's not that bad. It's much, much worse on some other platforms.
What does a toolkit have to do with a display server?! Especially in this age and year when pretty much no one writes native UIs anymore? Like, android, which is by far the most popular OS by user count has a huge proportion of web apps - apps are fundamentally driven by network effects, so the tiny user count a new Linux contender could muster up would be a rounding error.
This was decades before the "let's make everything a stupid webpage in an Electron box" movement, but you were likely running some GTK and Qt apps and probably even some Motif or Xaw stragglers, on a single desktop most days.
Yes, they could have said "out of scope" and moved on. TBH, I wonder if that's part of how we ended up where we are. There probably needed to be clear documentation at the right moments of "this is what we don't include, this is why, and this is how we recommend you do it outside the system."
This makes it feasible for car entertainment systems that only want to display bitmaps, but is easily extended to any future use case. There are a bunch of actually standard extensions now, implemented across all desktop Wayland servers, so many of these criticisms are moot.
(We're talking about user's desktop, not custom car entertainment compositor)
(Why does GNOME still matter? They've got the most developer resources of basically any group in the linux desktop space, and a large part of the market share because they're the default on a few of the larger distros)
There are lots of display technologies out there for Linux besides X11 and Wayland.
There was Mir from Canoncial, which is now dead. The project moved to using Wayland.
There was Freon from Google's ChromeOS that was announced in 2015 to replace X11 for ChromeOS, but it is dead. They are moving to using Wayland.
There was DirectFB, which has been supplanted by DirectFB2. They have been plugging away doing their own thing since time immemorial. Directfb2 even has Vulkan support now. Good luck getting KiCAD working on that.
And there is Surfaceflinger from Android. Which is actively developed and widely used.
None of these things would allow to do what people are complaining about what they are not allowed to do in Wayland .
> There's too many things people want to do that Wayland designed out of their system.
eye rolls
I'm not sure if Systemd falls enough into the same pattern, but I'm sure something better will emerge in the next few years.
But I also never had any issues with Pulse so I don't ever want to discount other peoples experiences.
Wheres game compatibility is great with proton in between apps are not with installation sucking, mostly replicating better native apps, and updated versions which are common and continuous in apps as it isn't in games usually leading to breakage.
I don't know about that. I've always been skeptical of the "X11 can't be fixed" claims, nobody has ever been able to explain that one technically, it's always "I read it somewhere" or "Trust me bro the code is bad (and I read that somewhere)". With XLibre, maybe there's life left in X11.
Gish gallop = “a rhetorical technique in which a person in a debate attempts to overwhelm an opponent by presenting an excessive number of arguments, without regard for their accuracy or strength, with a rapidity that makes it impossible for the opponent to address them in the time available.”, coined about a particular creationist’s debate strategy.
https://en.m.wikipedia.org/wiki/Gish_gallop
CADT = “Cascade of Attention-Deficit Teenagers”, describing a situation where software is re-written so often that filing bugs against it is useless, coined by jwz here about GNOME’s development approach: https://www.jwz.org/doc/cadt.html
At hindsight it seems such a stupid decision to fragment a small comminity by designing such a small protocol instead of revamping the existing X protocol to sane security stamdards
Xorg has security module hooks btw
Just to make the record straight, it's not about "hating" anybody or anything. And I really don't see the need to appeal to emotions here. It is about acknowledging that this way of doing things might, in retrospect, have been a bad idea all along and represents a technical dead-end. Departing from it, given the chance, is for the benefit of all in the long run (tech doesn't like carrying old bags around forever, and I suspect that your laptop don't hold a CD-ROM drive for similar reasons).
> if something doesn't hurt anyone then you should probably be allowed to do it
It would cost the Wayland compositors developers extra effort to maintain this capability for decades to come, it's not free. Moreover, those apps would still be broken by design (not in a position to do as good a job at positioning their windows as the compositors would do), so the compositors developers would, as a second order of annoyance, probably see their issue trackers filling-up with user complaints that are outside of their scope/power to address.
> this is the open source world
And the great news here is that those entrenched apps who refuse to adopt more modern UX paradigms (for the detriment of their old and new users alike, if I might say) will still be able to run through XWayland virtually forever.
Not a wayland issue.
No. That's how i3 and sway works, on purpose, by design.
I use sway, hence I claim to know how to do it in less than 2 minutes.
i3 precedes wayland, so again, not a wayland issue.
> A user should not have to learn config file formats in a graphical GUI interface.
If <app> requires user to <insert skill>, then user will need to <insert skill> in order to use <app>.
Well said, anon!
Meanwhile, maybe stfu with your opinions about my work flow.
To be honest, I've never seen a Linux desktop that most people would call "production ready". Even in the best days, X11 and Wayland have glitches, hardware issues, and stability problems that no other platform seems to suffer from. It took until Pipewire for audio to actually work well out of the box.
As for X11, KDE and probably others will run X11 for years to come, mostly because companies like Canonical and Red Hat ship LTS versions. Whether applications will keep supporting old configurations is another question (what software still runs on Ubuntu 16.04? I wouldn't know and I bet neither do most third party vendors), but the protocol itself isn't dying any time soon. It's not allowed to by corporate contracts.
What is dying, is corporate investment into X.org and X11 targets for some desktop environments. Developers and companies that favor X11 can come together and fork those projects, or join the dev team, to ensure their desktops work like they used to. Just because IBM doesn't want to pay developers to maintain such configurations doesn't mean they suddenly stop working, just that someone else will need to apply bugfixes from then on out. The only serious attempt I've seen from people who want to keep X11 alive was that fork from that antivax anti-DEI weirdo.
> The X.Org server, an implementation of the X Window System, was previously deprecated and is removed from RHEL 10. Note that the X11 protocol is not removed, which means that most applications will remain compatible through the Xwayland compositor. For more information, see Red Hat Enterprise Linux 10 plans for Wayland and Xorg server (Red Hat Blog).
(https://docs.redhat.com/en/documentation/red_hat_enterprise_...)
The main reason for this is that neither major DE has implemented multi touch gestures on X11. Not that they can't be.
There's several tools you can use for things like touchpad gestures on X11 and they work well, but aren't as nice as native integration into a DE.
UNIX was designed as CLI OS, the only companies that did great things in terms of desktop experience were Sun, SGI, and NeXT, so that leaves macOS when I feel like using a UNIX workstation, instead of running a GNU/Linux VM.
Even X11 was the outcome of UNIX wars, were X itself was made open, but CDE systems not, Keith Packard has a few talks on the matter, as he was there as it happened.
Have you tried wayland-client? When I made my custom application framework, since I had no previous experience I decided to start with wayland-client library, and then figure out what to use for X11.
My experience with it is that it is painfully sensible. Things fail when misused, which happens a lot (probably also because only few people actually wrote code with it so I was on my own to understand how to do stuff), but at the end they were fixable, and the only gripes I had were the protocols that GNOME didn't implement at the time. But I guess, if they are not implementing it right now, it means that they think it's okay if it does not work. (and actually I could also defend a lot of missing things in Wayland protocols, like the fact you can't position windows yourself)
On the other side, X11 just looks like a mess. When you start it feels like you have 2 options, XCB and Xlib. Old posts say that XCB is the modern one, but nobody uses XCB so in fact you may encounter bugs. Error handling is really poor, most of the errors are small messages written in stdout. You ask for things called "Atoms", and you send them/attach them to the X window. No feedback on whether it works or not, they mostly have weird names with prefixes like _NET_WM or _MOTIF. If you want to make an OpenGL window, for a long time it was not possible if you used XCB because GLX requires you to give Xlib handles, then came EGL-XCB which was supported by almost no driver because for some reason it seems that you need driver support for each X library you may want to use. When you start you're reminded of a slew of somewhat niche concepts today, like Visuals, Seat, Back pixel, Front pixel, which you are probably not expected to use today (in detail, I know, visuals may be useful in some small use cases, I don't know why the app is in charge of selecting the seat though, and pixel stuff is probably a dead thing). At the end the only thing that makes X11 bearable in my opinion is the fact that people wrote a lot of code with it so you can search on the Internet for the most part and find a snippet of code that should work for your use case.
Otherwise I don't really mind wayland.
I really have no other plausible explanation how they could miss so many potential usecases while rebuilding the display management ground-up: screen sharing, fractional scaling, different scaling factor for different screens, color profiles, HDR, toolbars and docking, window positions, and whatever else.
In the Wayland GitLab, there are comments in the spirit of "who would ever want to use this?" for a feature requests of something present in literally any sane WM...
They also, in typical Unix geek style, don't give two fucks about what the market wants / needs.
I have a better one: They designed for embedded devices first, desktops second or not at all. The first users of Wayland were things like vehicle infotainment systems, which operate under a limited mobile-like "one app at a time" system. Back then Ubuntu Touch (using Canonical's Mir) also looked like a prospective usecase for a new display system.
As far as I remember, the Wayland devs' approach to desktop support was "we made the basic protocol, now you desktop people either integrate functionality into the compositor (what GNOME did) or make your own extensions (what wlroots, KDE did), we don't care". With that kind of "leadership", no wonder it took years to reach even basic consensus.
That, unfortunately, seems to be Wayland's mantra.
As your theoretical "*nix geek" who mostly uses terminal windows, wayland and gnome provide an inferior experience to the daily driver software of 20 years ago.
Others are feature requests that there were recently released protocols for e.g. window restoration and cursor warping, but with adoption needing to pick up.
Nothing negative towards KiCad team as they and the community sort things out, but it's easy for others to read this and conflate "problems with application's Wayland support" as "problems with Wayland". It's a new platform for them, and support for a new platform will always have some growing pains.
Xwayland is also under continued development, and these distribution are not dropping X11 support through Xwayland, just native X11 sessions.
Yes, it's easy because that's explicitly what they say.
>The following problems are known issues in Wayland protocols or their implementation in desktop compositors, window managers or other layers in the display stack that are beyond our ability to resolve:
So we have two opposite claims. One from the developers of kicad in this write-up with examples and one from you above.
You have the organizations maintaining entire Linux distributions with countless applications they support giving their vote of confidence based on their experiences.
You have the organizations backing and developing Wayland.
You have all the developers of Xorg ditching it and working on Wayland instead (the person vocally claiming to pick up the slack recently had almost all their work reverted when it was found to have been completely broken).
That's a lot of people voting with their time (and in some cases, money) on Wayland and its capabilities. So no it's not my claim that Wayland works vs. KiCad devs, it's the claim of everyone that actually have skin in the display server game.
(They will also agree that some features are missing, but things like focus, graphical glitches and performance are not Wayland issues, just application bugs.)
Perhaps the Wayland developers could help developers transitioning from X11 to fix those issues because those issues make Wayland look bad/unusable.
But, to most users, switching to Wayland just means that everything got smoother, and easier ot use, with everything working. Even X11 applications will work just fine. Even if Wayland has an omission that is greatly upsetting to an individual, the X11 mode of the app will usually work exactly like it always have without leaving the Wayland server. Anyone using extremes like "unusable" (or "perfect"!) is not providing meaningful information and can safely be ignored.
edit additionally: your major re-write of your original post changing this can be hidden from most but I, and others, saw them and responded to the original with quotes in our own comments. This is more evidence for bad faith activity.
Editing a comment for clarification is not bad faith. It avoids misunderstanding and helps those reading it, even if some have already read an earlier version of it. It makes it sound as if you consider comments a battle, with changes being cheating or foul play, which... Is just wrong.
Nothing about my comment was bad faith or disengenious, nor did I say that I agreed with KiCad developers. I just said that, and will stand by, that it is erroneous to read their claims of e.g. performance issues when using their wayland platform code as being an issue with Wayland. If you write new code that is slow, you don't start by blaming your CPU, then your compiler, then your OS, and Wayland is generally known to perform better than X11 by virtue of being designed by people also working on the GPU driver stack.
Where did your ">it's easy for others to read this and conflate "problems with application's Wayland support" as "problems with Wayland"." go? That falsehood started this particular comment thread and everything it's about.
That statement is both still there in its entirely unchanged form, and still entirely true - quoting the comment as it appears on my screen right now, long after any edit window closed:
> but it's easy for others to read this and conflate "problems with application's Wayland support" as "problems with Wayland"
What are you talking about?
>A significant portion of the problems listed, e.g. performance, "unpredictable focus", glitches, freezes, etc., will generally be purely KiCad bugs
The issues have been looked into and they are purely Wayland bugs.
If things work on Windows, macOS and X11 without any platform specific ifdefs, the problem is Wayland ;)
That's not how Wayland protocol maturity works. Protocols of interest are picked up immediately and graduate to stable after wide adoption. The naming was also changed to "staging" instead of "unstable" to clarify this.
(Case in point, linux-dmabuf was only recently stabilized, and many protocols in mainstream use are not "stable").
> The issues have been looked into and they are purely Wayland bugs.
Bugs reproducible only with their Wayland platform code ≠ Bugs in Wayland.
> If things work on Windows, macOS and X11 without any platform specific ifdefs, the problem is Wayland ;)
Not at all how things work, no. :)
Yeah... good luck changing your protocol after it's been "staging" for 5 years and everyone has adopted it.
A staging protocol may end up being replaced and slowly deprecated, or have more breaking changes in new versions than you would find in a stable protocol, but a client using a particular protocol can rest assured that a server offering the protocol will adhere to the same version of the protocol contract the application was written against.
It is, though. If something works as you expect on the platforms where the majority of your users are then the weird one is just going to be ignored.
Platform integrations are a lot of code, which you might have bugs in, and why people tend to use toolkits that do the work and abstract it away for you. Even if platforms look like they're providing similar high-level features, they will look nothing alike underneath. If you roll it yourself and have bugs in your code, that's fine but not the platforms fault.
What is the point of Wayland?
If there is enshittification, it's intentional on the part of the developers, and I doubt they think it's enshittification so much as sage design choices made designing an architecture they think will eventually run on billions of devices.
No wonder.
IMHO window restoration is the job of the DE. Implement it once there, not in every application.
Wayland in general is all about leaving stuff up to the display server, with the display server representing the current user and their current window management preferences.
In which way was this transition the worst for you?
I'd guess an LTS release x years from now would be a different story. Even next year possibly, based on the pace things are going lately.
Indeed, that's not a problem at all, because there are zero such things I care about. The problem is that a lot of distros and DE's are dropping support for X even though Wayland still isn't viable at all for so many people, and LTS isn't forever.
GNOME 49 will drop X11 sessions completely. That in turn means that the default editions of Ubuntu 25.10 and Fedora 43 drop X11 session support.
https://www.theregister.com/2025/06/12/ubuntu_2510_to_drop_x...
Arch will presumably pick up GNOME 49 as soon as it's released, and so GNOME on Arch will also drop X11 session support this (northern hemisphere) autumn.
I know that most Ubuntu users run LTS versions, but still, those are probably the 3 most widely-used Linux distros in the Western world, and as such, I think the statement that "very few" things is false where it applies to Linux distros.
99.99% of stuff should work under XWayland.
Does Xwayland support running firefox on a remote server and opening it on my local wayland machine ?
I'm hoping the answer is yes, because every single time I've tried in the last few years, it failed and it's most definitely NOT a niche feature of X11 for me: I use it all the time.
But, I think if you really rely on X forwarding you should keep using X. The last time I used X forwarding the performance was significantly worse than newer protocols like RDP. X is a very chatty protocol, which performs poorly on a lot of networks.
See my comments about Wayland team not listening to their users. It is probably a niche feature FOR THEM.
Now, I most certainly agree that X over network is horribly inefficient.
However:
1. RDP is a freaking mess on Linux. It may be much better at the protocol level, but all the clients are horrible, and it misbehaves horribly across WANs and/or firewalls. And setting the whole fucking thing up is certainly *way* harder than typing the casual one-liner "export DISPLAY=<ip>:0; firefox&"
2. There is therefore no alternative to X11-over-the-net, and in this 21st century world of everything-in-the-browser enshitification, having to use X11 over the network is something I hit and absolutely rely on about once a week when configuring remote servers.Sadly, they are not.
KiCad kicked this press release out because RedHat broke mutter which broke XWayland which caused a whole bunch of us to file bugs against KiCad (and other applications) that were the fault of Wayland.
This caused a whole bunch of application developers to have to waste a bunch of time running down a bug that made it completely obvious that RedHat does ZERO testing of whether their changes break anything in the XWayland space.
I've been happily using KiCad under XWayland on Sway, I've had no complaints from relatives about the stability of KDE under Wayland, and I hear Hyprland is nice too.
You know what ... you're right. Since I'm on an atomic desktop, I shouldn't keep putting up with the abuse.
Thanks. I rebased from Silverblue to Kinoite. We'll see how that goes over time.
Nope. Sadly. Instant dialog box focus problems from kwin_wayland.
I switched to kwin_x11 (which KDE doesn't want you to use) and the problems all go away.
KiCad for some reason chose to paint the picture that all of these are status quo issues that are not getting solved... but the rate of progress has been pretty good actually.
Some of the issues they list are also very blatantly KiCad/wxWidgets issues and not really anything inherently to do with Wayland. Seriously, "Graphical glitches" and "Application freezes and crashes" are not problems caused by your Wayland compositor.
[1]: https://wayland.app/protocols/xdg-toplevel-drag-v1
[2]: https://wayland.app/protocols/pointer-warp-v1
1. Autokey. I use this to expand abbreviations for long words and phrases I use often. This relies on being able to insert itself between the keyboard and all userland apps, and this is apparently impossible under Wayland.
2. SimpleScreenRecorder. This relies on being able to access the window contents for all userland apps, and again this is apprently impossible.
Would I be right in thinking that both trip over because Wayland enforces application privacy, so preventing applications accessing other applications resources? And if so, why isn't there a "user root" level for apps that do need to interact with other apps?
Who is saying those are impossible use cases? I think your two apps have just not updated, that happens often with software.
I'll start with screen capture because it is easier. This one can be done on basically any Wayland compositor by using desktop portals + Pipewire, with the downside that applications must ask permission before they can capture the screen or a window. On KDE, XWayland apps can also capture the screen or a window, but it will also require a permission prompt. On some wlroots-based compositors, there are special protocols that allow Wayland clients to see other Wayland top-level windows and capture their contents directly without any permission prompts; for example, with OBS you can use the wlrobs plugin.
In fact, screen capture in OBS will be more efficient than it was in X11, as it will work by passing window buffers through dma-bufs, allowing zero-copy, just like gpu-screen-recorder on X11. OBS is a bit overkill for screen recording, but I still recommend it as it's a very versatile tool that I think most people wouldn't regret having around.
Now for Autokey. This one is possible to do, but I'm not 100% sure what the options are yet. Programmatically typing is certainly possible in a variety of ways; wlroots provides virtual input protocols, and there are other provisions for accessibility tools and etc. However it seems right now the main approach people have taken is to use something like ydotool which uses uinput to inject input events at the kernel level. It's a bit overkill but it definitely will bypass any security in your Wayland compositor :)
The more proper way to support this sort of use case would actually be by interjecting yourself into the input method somewhere. I don't know if anyone has done this, but someone DID try another route, which is to implement it on top of accessibility technology. I haven't tried it so YMMV, but I believe this is relatively close to what you are looking for.
Though, it has the caveat that it only works with applications that properly support accessibility technology (I would hope most of them...)
> why isn't there a "user root" level for apps that do need to interact with other apps?
Truth told, Wayland being inherently capabilities based, all of that could be implemented. Wlroots implements all of the protocols you'd imagine would be in that group, but it's just passively available to all applications by default. (I think they may support lower privilege applications now, too; there's protocols that convey security context and etc. for sandboxed apps.) The wlroots protocols are very useful, so they're also being implemented elsewhere.
Listing top-level windows: https://wayland.app/protocols/ext-foreign-toplevel-list-v1
Implementing docks and other desktop UI widgets: https://wayland.app/protocols/wlr-layer-shell-unstable-v1
If you wanted you could grant just as much capabilities to a Wayland app as before, and give apps the ability to interpose themselves between everything else, get and set absolute window positions, etc. it's all up to the compositors. Personally I think over time we'll see more provisions for this since it is useful even if it's not needed 99% of the time. Just don't expect too much stuff to work well on GNOME, they can be... challenging.
I love having to detect at runtime the compositor I'm using (and its version) and have bespoke code paths to work around their various bugs and omissions.
Definitely a recipe for reliable, usable, maintainable software.
> Unfortunately this is poorly understood due to it being generally poorly explained.
This reads like a "missing missing reason"[1]. People do understand it, and they explain why it's a dealbreaker. Wayland has had a decade and a half to grow some consensus and make these very basic things that work under X11 work. Instead of doing that, they're now relying on the main distributions just giving up on (the hardware) X11 servers instead of fixing this. I don't care if only one or two compositors that I don't run support the one thing that I need. That doesn't help me because those compositors don't implement other functionality I need. Having a stable, agreed upon, universally consistently implemented base of functionality that application developers and toolkits can rely on is a good thing.
This is a complete clusterfuck, and that's why there's user feedback. Trying to frame it as "people just don't understand" isn't productive. They do, and their criticisms have some validity. It's up to the Wayland devs to see if they care, and historically, they haven't.
[1] https://www.issendai.com/psychology/estrangement/missing-mis...
> Definitely a recipe for reliable, usable, maintainable software.
Honestly, tough. I didn't like dealing with Xlib/xcb, the weird error handling, or broken ICCCM implementations, but all of that stuff is typically lower level than most developers need to care about, since most developers are going to be using toolkits. If you need or want to go lower level, Wayland is what you get now. You don't have to do anything, you can always take your stuff and go home; the free desktop, though, is not going to be moving back towards X11. The rest of us will keep working to improve Wayland until it stops hurting.
Modern users have high DPI displays, variable refresh rates, multiple monitors, and panels with HDR color space support. X11 was just never going to work well for this. KDE Plasma 6.3, on the other hand, handles any of these situations quite well and I've been using it on a daily basis.
There are many users who can't even do real work without proper color management; it's so bad that for Blackmagic users the typical workaround is additional hardware. Retrofitting good color management into X11 is just not something anyone wants to try to do, it's not fit for the task. We have to move on, and Wayland is the best path forward for the foreseeable future.
> This reads like a "missing missing reason"[1]. People do understand it, and they explain why it's a dealbreaker. Wayland has had a decade and a half to grow some consensus and make these very basic things that work under X11 work. Instead of doing that, they're now relying on the main distributions just giving up on (the hardware) X11 servers instead of fixing this. I don't care if only one or two compositors that I don't run support the one thing that I need. That doesn't help me because those compositors don't implement other functionality I need. Having a stable, agreed upon, universally consistently implemented base of functionality that application developers and toolkits can rely on is a good thing.
Not a big fan of people throwing out psychology terms half-heartedly, but whatever.
The key misunderstanding is thinking that Wayland stops you from doing anything, but really from an end user's standpoint, the right question is "Can I do x on KDE?" because it is your compositor that really defines what your desktop is capable of in the Wayland world.
Developers have to deal with fragmentation by design. Wayland is not a superset or subset of X11, it's an entirely different thing altogether that happens to also cover the use case of applications talking to a display server. It also covers things like kiosks and embedded systems that X11 could be jammed into but was never a great fit for. Technically you're not guaranteed xdg-shell but that never seems to bother anyone.
This is not an accident at all though, it's an intentional strategic choice. Giving application developers less low level tools was a logical choice when looking at the types of hacks X11 applications did to implement features the desktops did not nominally support. This acts as a forcing function to have desktop systems properly support features that they need so that these features can properly integrate into the system. There's no equivalent to layer-shell in X11.
It is not expected to be a thing application developers are always happy about. People are rarely happy when agency is taken away from them.
> This is a complete clusterfuck, and that's why there's user feedback. Trying to frame it as "people just don't understand" isn't productive. They do, and their criticisms have some validity. It's up to the Wayland devs to see if they care, and historically, they haven't.
This was not a response to user feedback, it was a response to a question that revealed a misunderstanding. It's just that simple.
Everything from your list except HDR worked in X11 years before it started to work in Wayland compositors. Maybe not perfect, but better than any Wayland compositor could do the same until only a year or two ago.
The amount of time it took to get at least feature parity with X11 in Wayland stack is ridiculous. I'm not really sure it wouldn't be better if all that time went into X11.
- X11 has no DPI virtualization or way for windows to communicate their DPI awareness. DPI is all handled by toolkits and desktops. Poorly. With multiple monitors, scaling is often buggy or entirely incorrect, only really working for one of the monitors. (How much you notice this obviously depends on what your desktop is like. Inside GNOME and KDE with "native" GNOME and KDE apps only, it should work decently most of the time. If you're i3wm or anything though you're pretty much guaranteed to have a bad time.)
- X11 indeed does have support for variable refresh, but it doesn't really work very well. In my experience it has basically always been buggy and weird and caused things to misbehave and go choppy for no reason. Before they introduced AsyncFlipSecondaries in 2021, the behavior with multiple displays was essentially unusable. No matter what you do, you pretty much just have to live with tearing on VRR+multi monitor. Much better off disabled.
- And yep, X11 just doesn't have any form of HDR/color management.
> Maybe not perfect, but better than any Wayland compositor could do the same until only a year or two ago.
As far as DPI scaling and VRR goes, this is false. I adopted SwayWM 7 years ago (from i3wm) specifically because I wanted my laptop to actually work with DPI scaling when I docked it. I actually don't know when VRR started to work right in SwayWM because I didn't yet have a VRR display, I just know that it already worked right when I tried it.
Note that for much of that time Wayland didn't have proper fractional scale support, yet I had my laptop at 1.5x scale during most of this time. You'd be hard pressed to notice, because apps could still just render at 2x scale and then it would get virtualized and downsampled. That might sound bad, but that's also exactly what you get with macOS's display scaling, and people usually consider macOS display scaling to be pretty good. (To be more particular, macOS renders apps at either 1x or 2x, but then scales the entire framebuffer to get fractional scales. Clever... I guess.)
As far as color management goes... well, X11 definitely couldn't do it better than any Wayland compositor, since it can't do it at all.
This is the core issue, it seems. The Wayland transition is kinda like if Volkswagen said "we're now going to stop making cars, and focus entirely on making the best gearbox possible". Well what are people that just want to get around going to do?
> Developers have to deal with fragmentation by design. [...] This is not an accident at all though, it's an intentional strategic choice.
And this is what I referred to in my original post, when I said that I think this decision was a very poor decision. People developing applications have enough on their plate, they don't need more fragmentation to contend with. Especially cross-platform application developers. I know, I've been one.
In my view it would have been much better if Wayland had sought to reduce fragmentation of the Linux desktop. Instead it seems the Wayland developers decided to turn fragmentation up to 11 by just implementing a minimal core set of protocols and let the DE folks figure out the rest for themselves, and application developers deal with the fallout of that.
At least that's how it looks from the sidelines. On Linux I'm just a user that wants the applications I want to use to work. I've been running a Linux desktop as a secondary machine for two decades now, and based on that experience my feeling is that it robbed at least 10 years of development from the community.
I get that X11 just didn't have a future, but to me it seems the choices the Wayland developers made meant the replacement happened much slower than it could have. That is, we could have had a much better Linux desktop today than we do, had they made different choices.
Alas, we'll never find out. Meanwhile my primary desktop remains Windows, at least for another 5 or so years. Perhaps the Wayland-based desktop is ready then.
Even if it is a bit annoying, this pain is a temporary one. Users didn't really need to know what an X server is or how to use it, and likewise they don't really need to know what Wayland is... except for one thing, which is during this transition they need to know what the trade-offs are for "GNOME X11 Session" vs "GNOME Wayland Session" and so forth. But otherwise, neither of these things were meant to be marketed to end users in the first place. Unfortunately though, user's intuition is failing them: There is a much bigger difference between "GNOME Wayland Session" and "Plasma Wayland Session" than there is between "GNOME X11 Session" and "Plasma X11 Session", and it's not clear or obvious at all.
> I get that X11 just didn't have a future, but to me it seems the choices the Wayland developers made meant the replacement happened much slower than it could have. That is, we could have had a much better Linux desktop today than we do, had they made different choices.
To be honest, I don't know the answers. I think a lot of people see me routinely defending Wayland and think the reason is because I personally think it's wonderful, but actually I think Wayland is ugly and made many bad decisions. The wire protocol has no native 64-bit integers. I think that the GNOME folks are dumb for not accepting server-side decorations as a reality and figuring out how to make Mutter handle it, even if it involved working out out-of-process stuff for it. Trying to deal with the GTK/GNOME developers for trying to work on a problem was so frustrating I flat-out deleted my GNOME GitLab account. I also think that it is unfortunate that we already have a fair amount of cruft in the form of unstable, staging, ext, etc. protocols that are sometimes available and sometimes not. Even with all of that in mind, it's so blatantly obvious to me that Wayland is the future for Linux, at least right now. There's no better option emerging, and frankly there are no true deal-breakers with Wayland... Just challenges.
Admittedly, part of the reason why the case for Wayland feels relatively weak now is just because the X.org server got a lot more usable in the last decade or two. When I first jumped on Linux, the X11 server we used was XFree86. There was no hotplugging; if you wanted a new monitor or keyboard to work, you had to restart the X server. Once hotplugging was added, it was unstable for a long time and pretty routine for plugging in a monitor to crash. Multi-GPU situations are still pretty hackish though they do sort of work. In 2013, X11 worked on touchscreens, but it was extremely unstable, and it wasn't uncommon for things to get "stuck", or the X server to simply segfault when touching the screen. Until 2021, variable refresh rate was basically unusable for multi-head configurations, since the primary head drove the buffer flipping. The Linux graphics stack improvements with DRM and KMS became a part of the X11 experience, as did the work done on libinput to improve touchscreens and pen tablets. It worked so well that many people wonder, why not just keep doing X11 then?
I just think there's no future in it. It's not that it's physically impossible; obviously, Microsoft is able to make all of its old systems cope reasonably well with a modern desktop compositing system, including complex things like DPI virtualization. It's not literally impossible for X11 servers to fix these problems. But the thing about a lot of those improvements, including the improvements to DRM, KMS and libinput, were investments in the future and backporting them to X.org helped improve them quite a lot. Trying to retrofit something like DPI virtualization or color management into X11 would be a massive unthinkable time investment that would mostly be in service of a protocol and codebase that already felt dated by the late 90s. It took years just to make a good color management protocol for Wayland where it's actually something that slots well into the design! And it's not just "ha ha wayland developers dumb", the thread is huge and sprawling with legitimate concerns mostly surrounding how to do color management right. Spending that time on X.org just feels like it's a waste. If you try to clean up the unbelievably vast amounts of legacy cruft, you will lose compatibility with a lot of older software, somewhat defeating the point of keeping X11 around. If you try to work around it, you will surely wind up spending an awful lot of time trying to not break things that haven't been updated since George Bush was in office. (In some cases, Senior.)
Maybe I can't make the case to everyone for why X11 is such a bad investment. I know a lot of people have a negative knee-jerk reaction to the idea that all legacy code must be thrown away and rewritten in Rust and other trendy things, and even something as old and weird as the X.org codebase just isn't enough to convince them that this is not one of those cases. Even in that case, I don't think the case for Wayland is really as weak as it seems based on its flaws. To be fair, I think most people complaining about Wayland are fundamentally right, but often frame things in a fundamentally poor way. Very few of the limitations of Wayland compositors that exist today are inherent, and many of them are getting resolved on a month-to-month basis. When developers claim "this can never be done because I don't have something like SetWindowPos", that's just annoying. Any feature can be done without direct access to these sorts of facilities, and I think that Wayland pushing window management tasks back to the window manager is something that will age very well even if it is painful at first.
I will definitely acknowledge is that for application developers, its annoying that you can do one thing on Windows, macOS, X11, BeOS, basically every other desktop system on Earth, and then you have to special-case that thing on Wayland. That's definitely going to be painful for developers who want to write software that runs directly atop Wayland. However: Open source software does not have the benefit of being able to move fast and jump on emerging trends as they start to become popular. I think that the developers of Wayland saw all the way back in 2008 that the longer term future was going to be different when it comes to window management. Obviously, they saw that desktop compositing would eventually be everything. But I think they also saw that for both privacy and security reasons and for the benefit of better window management, giving direct access to position windows is an artifact of many features that really ought to be provided by the window manager. If they wanted Linux to have a desktop system that felt "modern" in 2030, they needed to start making the moves towards that in 2008, because it wouldn't only take an enormous amount of time to make Wayland happen, but for the ecosystem to adjust to it as well. I think they also reasoned, correctly, that the vast majority of developers would not be using Wayland directly, but would be using GTK, Qt, SDL, etc. which I think is still true.
Also true is that some software and definitely some UI toolkits will never fully be able to cope with the windowing model that Wayland presents them, but this isn't actually the dealbreaker everyone seems to think it is.
First of all, I believe XWayland is here to stay for a long time. We're really not all that close to even being able to remove XWayland and I don't anyone really wants to soon. If developers are unable or unwilling to work to make their apps work on Wayland, that is fine. X11 is still here. Some developers will bravely start huge efforts and it will wind up benefiting the whole ecosystem by possibly introducing new protocols, providing tons of experience reports, and probably making compositors more robust all at the same time. A good example is Godot. Other software is just waiting for now and forcing XWayland; an example of that is Krita. A lot of eager enthusiasts may be bugging developers to start getting things going, but I think by and large there's no real reason to rush. For most users, XWayland is good enough.
Secondly though, I think that even old toolkits that rely on concepts like the ability to directly introspect and modify window geometry can be made to roughly work. Obviously, Qt 5+ do generally work on Wayland, with some limitations. (Well enough that most apps don't really have to change anything.) The winewayland.drv in Wayland makes Wine generally work on Wayland, with some quirks (probably a lot less than you're imagining, especially as of late.) While you obviously can't do everything the same, it is possible to virtualize old APIs and use workarounds. I don't think all of the old apps are forever doomed to XWayland as it may seem today.
Will the Wayland desktop be "ready" in 5 years? I think it will be "ready" in closer to 1-2 years, at least if the current rate of progress keeps up. Rather than being worried about the Wayland desktop being ready from the compositor/protocol/application end, I'm more concerned about the continuing progress on the NVIDIA end, which has been promising from multiple angles but still a bit slow moving.
My attempt did last longer than previous attempts. But in the end, I gave up due to all the bugs, again. Broken input, broken rendering, broken shortcuts, broken accessibility (not just a thing for those losers who chose to be born disabled) ... it's like Wayland isn't even trying. It's hit-or-miss whether native Wayland programs or XWayland-using programs are more broken.
If you want stability and/or features, X11 remains the only choice, even in $CURRENTYEAR. ... actually, it's quite possible that all the X11 devs moving toward Wayland is responsible for the significant decrease in X11 bugs I've seen recently ... or it might just be that there's more RAM.
In theory, Wayland is beneficial for the small fraction of users with a high DPI monitor. In practice, if you try to enable it, you get a small fraction of programs that obey it correctly, a moderate fraction of programs that badly mix scaled and unscaled elements, a small fraction of programs that end up double-scaling somehow so everything is too large, and a large fraction of programs that remain tiny. Your machine is much more usable if you just leave everything small and sit closer to the monitor, occasionally using per-app controls that work just as well on X11 anyway.
I have not actually seen any other benefits of Wayland, people just tell me they allegedly exist. Sandboxing windows away from each other is pointless since all clients are unsandboxed with the same UID anyway. "All in one process" is exactly the opposite of a feature; it just means that all crashes are fatal instead of usually recoverable like they are on X11.
Maybe Wayland should spend a decade or so running its protocol to a server inside X11 first to shake out the bugs?
EDIT: on further thought though, it's really odd that they still haven't added in optional APIs for a lot of basic window operations...
That's because like you mention, wayland doesn't look at things as "windows" like X11 used to. It's got surfaces and compositors so it's a really rather different design than the previous systems which is why there's been such an issue with transitioning some kinds of applications and why it's been so hard to get some of the window related protocols to be agreed upon. There's been a decent number of attempts at the positioning protocols that have been kiboshed because there were effective security issues because the protocol would imply that a client could take over the screen from the intended application that the user was using, if the compositor fully follows the protocol or worked the same way that X11 did. Supporting all the different use-cases like this has definitely made progress slower and harder to keep up but personally I think it's going to end up with a more comprehensive and future proofed system once it is finally getting those last couple of things that take it from an 85% solution to a 99% solution.
The only bugs I have seen in KDE are in sddm, but I managed to find a theme where they don't exhibit.
I've been hearing about these problems for years and if all that's missing is someone to own up to fixing it, it's worth finding out.
edit: looks like pointer warping was added to the protocol last week: https://lore.freedesktop.org/wayland-devel/aEw0AP7h6T8l11ug@...
The idea is to avoid clickjacking, eavesdropping, phishing-esque windows, you name it, all which only works when an application has freedom to find other windows, place itself and steal focus and input. Even just stealing a cursor at a bad time might lead an in-progress password input to end up somewhere unintended.
It was a good intention, and it's hard to figure out where to draw the line between convenience and capability and secure design. It's absolutely impossible to ask, as everyone will demand everything, claiming even the smallest feature is the foundation of all modern computing.
Some of these things are now coming in ways that still aim to keep explicit behavior and decent control, but enable the needed usecases. Cursor warp, session restoration, picture-in-picture, etc.
If letting the application ask nicely is a good enough security measure, then you never needed to ask in the first place. When a user wants to use an application (or, what they think an application does), and the application just says "for the app to work" when the OS queries it for a reason why it needs permissions, the user is going to click permit every time. From a practical security standpoint, the application could just as easily say "I'm going to take control of your mouse OK/cancel". Which is what happens on X11, except applications just take control of your mouse whether you want to or not.
The web is a different beast because people will visit sites on a whim, plus there’s things like redirects to factor in. Friction for visiting sites is very low, which makes the spam problem much worse. Users’ desktops are a very different environment — nearly all programs that are installed are there because the user explicitly willed it. Apps can’t install themselves and users install apps at a much lower rate than they visit sites, and so the only time there’s a “spam” effect is when setting up a new machine (which could be ameliorated by account migration tools copying permissions). Furthermore, if apps start acting abusive there’s a good chance that users will remove them and seek replacements, and so it’s in apps’ best interest to not do that.
As for Android, that’s simply a bad permissions model. The iOS/macOS model in which prompts are shown when the user tries to use an associated feature is much better and appropriately triggers mental red flags when incongruent permission requests appear.
It’s never going to be perfect, but third party devs have repeatedly proven that full access to everything all the time is not a model that works for anybody but power users and above.
I don't see how all-or-nothing is better than letting the admin whitelist what they need and blacklist that they don't
Working with existing applications as is requires a ditect mapping, and any restrictions or asynchronous prompts would break any existing assumptions in platform agnostic code, so it wouldn't solve things completely.
If you make something possible to do something with a permission or configuration, app developers just tell users to accept or configure to not ask, and then we're worse off than if there was no permission at all: the security is bypassed and only the inconvenience remains.
It takes a surprising amount of thought and work to do this in any meaningful way, and it cannot be done in a way that isn't somewhat disruptive.
For multi-window applications you're not inside "your own window", you own many windows. Are apps not allowed to get and set properties of windows they spawn under Wayland?
I haven't worked on desktop UI in years, but that's very surprising to me if true.
Depends on what you're calling properties of the window, wayland does of course have a number of things like that but not all of them are the same as X11 used to be. I don't believe it's got a way to get the position of your own window, and does not have a way to set the position at all since that's considered a property of the compositor's handle on the surface IIRC (not exactly the same as the window, since the compositor can be putting decorations on the surface like the title bar, controls, etc.).
A lot of it is consequences of moving some security fences around as other commenters have mentioned, because over the decades a lot of applications (not necessarily on linux or X11, but it has happened there still) have used those other barrier's leakage to do nefarious things like steal passwords, pop up ads on top of what you're doing, etc.
I would definitely support an argument that they swung the pendulum further towards "secure by default, even at the expense of what people need" but I'm actually happy they did, because it's quite a bit easier to add the functionality in after you've got something that's secure, rather than design a new barrier that breaks existing things after the fact.
Well, technically Wayland has no such thing as properties. It only has requests and events on objects, and no protocol behave like an arbitrary key value store the same way X11 atoms do.
You can't ask Wayland how big your window is or should be for example, you decide how big it is right now when you submit a graphics buffer in a requests, and the Wayland server will tell you in an event if it would like it to be a different size (say, because someone dragged a server side decoration or because the window became fullscreen).
A key difference between Wayland and X11 is that Wayland is very explicit in how functionality is defined and added.
Note that Wayland objects including surfaces does not have "properties", just requests and events. You create a surface object, create an xdg_toplevel role object to make it into a moral window, and send requests to attach and commit buffers with content, to request fullscreen, etc. In turn you get events if the display server would like you to change state, when it's a good time to start painting, etc.
It's not like X11 where a window is an arbitrary key value store that you write stuff to and cross your fingers in order to get particular behaviors.
So a very basic problem in a multiwindow app is: open a new window. Move it around. Close window. Reopen window, and reposition it where the user last placed it.
Normally that requires windows knowing where they are in absolute coordinate space on the display. From what it sounds like, that's not possible in wayland?
Note: I don't think it's productive to talk in terms of Wayland or X11 abstractions or terminology, since the problem is very simple and something that's pretty trivial to do on any desktop for the last ~25 years. Regardless of how Wayland presents the data to an application we can agree: an app opens "windows", a user moves them around, and then the app may want to recreate equivalent windows at the same position later, right?
Under Wayland, this is not the responsibility of the application, but the responsibility of the display server. You tag the window using the new toplevel tag protocol, and the display server will remember things like user position, size, always-on-top settings, and similar.
> Normally that requires windows knowing where they are in absolute coordinate space on the display. From what it sounds like, that's not possible in wayland?
It is neither possible to know where a window is nor to place it. That is purely up to the server, and under Wayland the goal is to tell the display server what it needs to know to create the UX the user would want - with a recurring focus on respecting user preference over having applications enforce the developer's preference.
But, it's important to note why it's made the display server's reponsibility: because the alternative was already broken under X11. Take a multi-window app that wants to open an old-fashioned "tool" menu. The application wants to place it to the left of the main window, which seems simple - until you realize it's not.
If the window opens fullscreen, the window would end up off-screen or on a different screen - okay, so we check if we're fullscreen and overlap the window instead. If the window opens near a screen edge or on a small screen, it might be too close to the edge - okay, so we also check if the left side of the main window is near a screen edge. Simple enough so far.
But then you run a tiling window manager (i3, awesomewm) and all new normal windows become tiles that pop up after predetermined rules, and random floating windows will be an error. Or you run PaperWM or Niri where the screen has an infinite horizontal size and so checking if a window is near an edge is always incorrect as the edge moves as needed. Or you run a VR window manager (we have those now!) so windows have not just X and Y, but also Z, pan, tilt and roll that the application does not know how to manage. Or you have a display server running on one of the OLED monitors that fold in and out like a recent CES lenovo laptop. Or...
Applications trying to micromanage their windows are effectively re-implementing a window manager that is always going to be making very heavy and wrong assumptions about the current window management paradigm and end-user preference. Instead of porting already broken duct-tape from X11, Wayland works on protocols that describe the intent properly - for example, by describing that an auxillary window is associated with the parent and should default to a placement to the left of it, rather than manually moving it.
(My personal opinion, unrelated to any project, is that traditional multi-window is a very fragile legacy design paradigm that doesn't make any sense, and that keeping operations to a main window and only using windows for isolated tasks - e.g., different workspace, file selectors, etc. - gives much better and more stable UX. Splash screens also no longer belong in a world of multi-tasking - just open the main window immediately, and if the app needs additional time to prepare, show the "splash" in the main window and transition later. That way, the user can multi-task and place the window instead of being interrupted by an application thinking they should cover up the center of the screen and randomly glitch windows in an out of existence.)
</walloftext>
That's all well and fine, no one is forcing you to build or use software this way. But there are domains where this is the predominant UX design and it's proven to be robust for decades.
Reading between the lines a bit and from browsing some mailing list posts/gh issues, it seems like Wayland developers have a deeply held arrogance towards application developers that are surprised to find out the applications they have been developing for years are "wrong." The truth is that GUI software on Linux is already a minefield (which is why most people don't bother to support it) and making it less-like-Windows is not going to make it easier for people to port their desktop applications. I get the desire for targeting things-not-like-Windows (tiling WMs, VR, tablet/mobiles, etc)... but those aren't desktop applications.
It seems crazy to me that there's so much feedback from desktop application developers that is being ignored or dismissed.
Nothing about it is robust, it just exists. It has been around for decades, sure, but it also has not been common or popular for at least a decade or two now. It primarily exists in old applications still rocking their original, unchanged UI.
I have sympathy for existing applications, but I strongly believe it would be entirely inappropriate for a new application to be written with such UI - it was never a good idea, nor did it ever work well. It was just an idea that we have moved on from.
> It seems crazy to me that there's so much feedback
Not specific ot Wayland, but there is always absurd amounts of "feedback" to any high profile projects, which unfortunately means that most of it is useless noise, hit-and-run tantrums over the mildest inconvenience, and "ideas for solutions" by people who spent less than 5 minutes trying to understand the problem. This in turn means that it can sometimes be harder than it should be for good feedback to make it through.
Just that last time I had the application on a side monitor doesn't mean it should move itself after launching. Its especially bad if you often reconfigure monitor layout (for example laptop sometimes using external monitors).
The problem is they want it both ways. If they're not willing to support literally every use case that X supports, then Wayland should merely exist alongside X, like Emacs alongside vi, rather than removing X from so many distros and desktop environments.
Volunteers own their own life and time within it and have no obligation to pick up arbitrary projects and tasks. The primary way to make people do something no one volunteers for is to hire them and pay them for it, but no one is interested in that either.
(One person did famously, and very vocally, volunteer and do a lot of work, but unfortunately almost all of it had to be reverted recently after it was found to break everything.)
2. Wayland and X does, for and enduser, coexist through Xwayland. You just no longer run a "native" X11 display server that controls hardware directly. Most Wayland servers afford Xwayland some slight additional controls for just the X11 windows, allowing applications to work seamlessly, so everything is fine.
And no, the "most" qualifier is no issue at all as applications relying on such control also only worked with some X11 window managers.
Chances are "cursor warping" here refers to how "cursor locking" is typically done in win32 (every time the cursor moves, record the distance and reset it to the original location). Ironically, in the announcement about cursor warping being released, they say that it's not reliable for that use case, but that a "cursor lock" was already implemented. So it would be funny if KiCAD was just too stuck in Windows mentality to realize that what they needed was already supported.
Furthermore, XWayland is not going away. If you are unwilling to support native Wayland, the way to go is somehow disable native Wayland, like by unsetting WAYLAND_DISPLAY early on in the code before initializing the toolkit or something. Krita does this and it works just fine, although it's not ideal since features like HDR or display scaling will suffer. (But does that even matter for KiCad?)
Tl;dr: reads more like developers not happy about the direction of Wayland than an actual reasoned position. Seems confused about the implications of the Wayland session. I wouldn't worry about this. You're still going to prefer the Wayland session sooner rather than later.
Well put, guys! This is the way. It wasn't broken, nobody needed to "fix it". Now they "fixed it" & it IS broken, it is not your job to pick up the pieces! I tip my hat to you for having the balls to just plainly state so.
Every single time, I had to go back to X11 because shit simply don't work.
At this point, I am dead convinced that Wayland is simply broken by design.
As a matter of fact, they justify their existence by systematically pointing out how broken the architecture of X11 is and how a "modern" replacement is severely needed.
True, X11's architecture is indeed bad and creates lots of problems.
However, unlike Wayland, it DOES WORK.
Also, and very unfortunately for Wayland, the team working on it seem oblivious to the fact that trying to replace a badly designed system does not automatically make the replacement any better.
At this point, I would call Wayland a complete failure.
Worse, they've been at it for over 15 years and it is still fundamentally unusable.
The fact that Ubuntu is planning to deprecate X11 is, at this point in time, a catastrophe as far as I'm concerned.
I've also felt no need to use KiCAD whatsoever. There are better open source EDA tools out there.
Wasn't cursor warping protocol just merged?
Err no. I don't know why EDA guys have this weird idea that cursor warping is totally normal. DesignSpark PCB does this too - when you zoom it warps the cursor! Wtf is that?
Kicad has pretty awful UX so I guess this crazy view isn't that surprising.
> things like being able to position windows or warp the mouse cursor. This functionality was omitted by design, not oversight.
Yeah again... I'll give you window positioning, but an app should never warp my cursor. It's mine. Get your stupid hands off it.
There are shortcomings to the current/recent state of Wayland (KDE hasn't had support for storing window positions until Plasma 6.4! HDR and VRR are missing from many compositors (and X11 DEs to be fair)! Fractional scaling doesn't even work right in many Linux applications!) but when it comes to design decisions, I'm mostly on Wayland's side.
It's one of the Quirks^tm of that field. Newcomers to the field go "WTF??" but the old hats go "yeah and you'll learn to appreciate it."
And you do learn to appreciate it. the cursor warping in KiCad is absolutely essential to high level operation because it means you don't think where you're zooomed to now, you point, you zoom, you've zoomed. Once you get used to some of the keyboard shortcuts to fly around the board, you get used to focusing on the center of the display rather than having to eye around looking for the component, which might be buried in a few layers of traces and vias on-screen.
Hmm I'm not sure. I've used NX, Pro/E, Solidworks and Fusion 360 very briefly and none of them did it. Which ones do?
It's much more a feature of specifically 2D CAD suites it seems; 3D comes with a different paradigm of movement, and in 2D CAD you're working in a different mindset: 3D CAD is almost all CSG, whereas 2D CAD is mostly targeted at emulating a drafting table.
Interesting. I tried very much every EDA available on the market and Kicad has no contest. Easy to learn, doesn't get in the way and you can design boards in no time.
Contrast with e.g. Altium. That one, in my opinion, is a prime example of awful UX. You have to constantly battle it to do anything.
Geda is dead now but I remember it being basically worthless.
Eagle seemed like it should be good but they've somehow screwed up every possible UX decision, sometimes in ways that I wouldn't have even thought of if I was trying. They somehow screwed up copy & paste! Look at this absolute insanity:
https://youtu.be/XHwRnunzQUE?t=35
I wonder what Tantacrul would say about that.
DesignSpark PCB is actually quite good. It's free with no limits but not open source. Has quite a dated GUI and weird zooming but other than that the UX is one of the least WTF-y I've seen.
Kicad is very powerful but the developers are clearly actively hostile to good UX.
Horizon EDA is based on Kicad's engine but fixes the UX. It's quite good but it does have a slightly confusing component model, and I have found it to be kind of slow sometimes.
I haven't tried LibrePCB yet - it does look quite good. Going to try it out for my next project.
You can't implement a circular menu without pointer warp (you can, it just sucks).
What if the hands are smart? This is a rather primitive view on UI complexity. While you should be able to block the app from changing your pointer, it doesn't make sense to not have the functionality for when it can help users
I have never seen a good reason for cursor warping.
In fact the Wayland devs are the primary group of people maintaining what is left of X11.
The reality is that a lot of X11 design is simply a bad idea. Which is what one would naturally expect given its pioneering nature. By the mid 1990s it was already obsolete and didn't match up with how hardware worked nor how people were using computers.
What has allowed it to persist to this day in Linux is more along the lines of:
* we just that we had a really good open source implementation with a very dedicated developer base and some commercial support from companies like Redhat.
* compatibility with X Servers other then XFree86/Xorg was no longer relevant since the rest of the world has long abandoned X11. So aside from a few nitch cases were people wanted X11 apps on their Windows desktops using properietary X Servers it no longer really mattered.
* X11 allowed extensions (most of which didn't work with network transparency, btw)
* Widget authors, mostly QT and GTK, went through great efforts to avoid using X11 and working around limitations.
KiCAD is just a unfortunate case. They use a kinda odd toolkit, wxWidgets, and happen to depend on a lot of X11 specific behavior for some of their application's features.
So it is less of a situation of Wayland devs not understanding X (they probably are some of the few people that actually understand it deeply).
Wayland actually has really good X11 comptatibility through XWayland and for most applications it doesn't cause issues. But for KiCAD it does. And they are just being honest about it.
Accomidations are being made for KiCAD type behavior and probably KiCAD will update and change things to meet them somewhere in the middle and in not too long it'll become a forgotten issue.
Which prominent wayland developers were maintainers of Xorg in 2004?
I keep reading this -- sometimes, verbatim. I don't know if you are just posting the same stuff everywhere you can, or it's in the database of some LLM bot, but it wasn't true the first time I saw it a week ago, and subsequently incorporated my response into my article here:
https://www.theregister.com/2025/06/12/ubuntu_2510_to_drop_x...
It's still not true.
The same mostly Red Hatters who maintain X.org on Linux are the same people designing Wayland, but there is a lot more to X11 than X.org.
As I replied to someone -- you? -- last time:
« There's a crucial but often overlooked distinction here. Yes, X.org develops the reference implementation of X11, but it's not the only implementation, and it never was. X.org was forked from XFree86 around 2004, and although development is dormant, XFree86 still exists.
There are or have been multiple active forks of X.org. OpenBSD uses Xenocara, developed independently. The FreeBSD X11 server and NetBSD X11 servers are their own forks, too. Although it's very different, the X11 server for Apple macOS, XQuartz, is also still around – even if it's not bundled any more.
The proprietary UNIX variants that are still in maintenance also have their own ports. Solaris 10 offered a choice of three but Solaris 11 has only its own version of Xorg. AIX has AIXwindows with its own X server. HP-UX offers two [PDF], one for HP Visualize graphics cards and another based on XFree86 for other GPUs. Before XFree86 was mature, there were a number of proprietary commercial X11 servers for Linux, such as Metro-X and Xi Accelerated-X.
Windows has its own GUI, of course, but it's been possible to run UNIX binaries on Windows NT ever since the first version, Windows NT 3.1 in 1993 – and since X11 runs over the network, the machine running an X11 app (the "client") can be a different computer to the one displaying the app (the "server"). As such there are multiple X11 servers for Windows, both for local and remote apps. Some are proprietary commercial servers, such as OpenText Exceed, X-Win32, Netsarang Xmanager, MobaXterm, and X410, among others. There are also multiple FOSS X servers for Windows, including VCXsrv, Xming [note, HTTP site], and Cygwin/X.
Many of these use code from X.org, but that's the whole point of FOSS. They aren't written by or maintained by X.org, and even if it and all Red Hat staff stop work on X11 completely, that doesn't mean these downstream projects will suddenly cease to exist. »
Some if not most of these bugs are 100% application bugs, very few actually used wayland compositors have performance bugs for example (but your app running in wayland native might).
With what a dumpster fire X11 has been lately its a bit weird to bet on it for your application.
Yes, just saying "Wayland is only supported through XWayland" is usually a really easy solution that does in fact just work.
> X11 on its own is dead, and things like KDE do very little development on their X11 version.
Eeeeh... I think calling X "dead" is hyperbolic. It is less actively developed, and GNOME and KDE are migrating away from it. But it still works approximately as well as it ever has, and pretty much anything except GNOME and KDE is quite likely to continue working for the foreseeable future.
- Sent from my laptop running Xorg
There's a film of jankiness that permeates X that I just don't get on Wayland. Animations don't drop frames. Things happen when they should. My text actually looks crisp. On Linux!