These problems exist because Wayland’s design omits basic functionality that desktop applications for X11, Windows and macOS have relied on for decades—things like being able to position windows or warp the mouse cursor. This functionality was omitted by design, not oversight.
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.
> 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].
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.
dsr_ · 3h ago
To draw a possibly inapt analogy: it was clear at a certain point that CVS, the king of versioning systems, was going to be replaced. It also seemed clear that any successful contender would seamlessly import from CVS, but not necessarily from any of the unsuccessful contenders, so it made sense to wait and let everyone else fight it out.
(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.
zppln · 3h ago
> out of their system
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?).
IshKebab · 2h ago
Yeah I think the fundamental mistake they made was trying to standardise a display protocol without a display server.
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.
tannhaeuser · 3h ago
> Win32
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.
LorenDB · 3h ago
Not directly Wayland specific, but vaxry (Hyprland guy) is trying to get up a new standards body to replace Freedesktop.org. That could possibly accelerate the coming of a major shift around compositors.
jeroenhd · 2h ago
I've been using Wayland for years and most applications will just work, either under XWayland or natively. The only problematic ones are the ones with incomplete Wayland implementations and the ones relying on the complete lack of security design on systems like X11 of Win32. The biggest blocker for me has always been Nvidia, and that problem was solved years ago. Meanwhile, whenever I drop back to X11, I'm reminded that things like multi-touch gestures are plainly broken on X11 mode in ever DE I've tried.
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.
ciupicri · 1h ago
> xorg-x11-server is removed from RHEL 10
> 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).
Wayland messes up Visual Pinball as well [0]. VP depends on being able to place the main playfield window, the backglass window, and the Dot Matrix Display window in specific locations on specific monitors mounted in the cabinet.
It's a poor decision. Unless you're IBM/Red Hat/GNOME. Then it's clearly the correct decision for increasing profit. Since GNOME desktop (and mutter) is the only wayland desktop of the dozen incompatible implementations that supports accessibility (they invented two new protocols for it; disregarding existing solutions) it's basically a take-over of the entire linux desktop business space. No other wayland DE is ADA compliant and the Gtk treadmill will make X11 and it's very solid accesibility less likely to work with any application. Sort of a combination gish gallop and CADT so that they're the only linux desktop left that fits business use cases.
senkora · 2h ago
I had to look up some terms, so for anyone else:
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.
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
jhoechtl · 3h ago
We have to investigate if Windows and or Apple had their fingers init.
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
justinrubek · 3h ago
People were and are free to do so. They've chosen not to, though, so far.
arghwhat · 3h ago
A significant portion of the problems listed, e.g. performance, "unpredictable focus", glitches, freezes, etc., will generally be purely KiCad bugs.
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.
phkahler · 29m 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.
IMHO window restoration is the job of the DE. Implement it once there, not in every application.
superkuh · 3h ago
>it's easy for others to read this and conflate "problems with application's Wayland support" as "problems with Wayland".
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.
arghwhat · 2h ago
> 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.)
DrillShopper · 1h ago
> 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.
delfinom · 2h ago
Window restoration was not recently released, it was put in as experimental and it'll probably be another 5 years before it's available on stable distros as a non-experimental flag protocol.
>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 ;)
arghwhat · 2h ago
> Window restoration was not recently released, it was put in as experimental and it'll probably be another 5 years before it's available on stable distros as a non-experimental flag protocol.
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. :)
duped · 1h ago
> Not at all how things work, no. :)
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.
IshKebab · 2h ago
> Protocols of interest are picked up immediately and graduate to stable after wide adoption.
Yeah... good luck changing your protocol after it's been "staging" for 5 years and everyone has adopted it.
varispeed · 2h ago
But from the post it sounds more like Wayland is just enshittification in open source fashion. Fewer options traded for...?
What is the point of Wayland?
dekhn · 58m ago
The point of wayland was that the developers of X11 with the greatest experience concluded they no longer wanted to work on Xorg, and designed a new protocol taking into account their experience as well as knowledge of how desktops have changed over the past 40 years.
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.
reisse · 11m ago
I have a harsh opinion - the real problem with Wayland is that its authors and/or maintainers are *nix geeks, who never used anything more complex than X11 on an IBM Thinkpad with a maybe second 4:3 monitor attached. And they daily drive a few dozen terminal windows, Firefox and maybe Thunderbird.
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...
poulpy123 · 2h ago
I don't have the knowledge to judge these specific issues, but the transition from X11 to Wayland was the worse I've ever seen. Worse than the python 2 to 3 debacle, and it seems even worse than the Perl 5 to 6 transition (that was resolved by not doing the transition)
mariusor · 2h ago
What am I missing? For 99.9% of existing Xorg applications the transition should have been transparent due to the existence of XWayland.
In which way was this transition the worst for you?
DrillShopper · 1h ago
The article talks about the many open issues with Wayland that do not exist in X, if you want some examples.
mariusor · 1h ago
Which seem to be self inflicted, if I'm not mistaken.
It think this one is interesting since it highlights that Wayland is not meant to be an exclusively window manager API. It includes things like kiosks, car screens, etc, where the concept of a window doesn't even exist.
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...
simcop2387 · 2h ago
> 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.
DominoTree · 3h ago
I've been using KiCad on Wayland for years and didn't even know I was missing out
Vilian · 5h ago
Xwayland isn't going to die in 10 years, it's fine to keep using that, thise bugs happens with KiCad running as Wayland or in xwayland?
dvdkon · 3h ago
KiCad seems to work fine under XWayland in my experience, with some severe bugs under Wayland (and not just window management & cursor warping-related, though that's a problem too).
jchw · 2h ago
Many of these limitations are in fact not Wayland issues and just limitations in KiCad (and probably more generally, wxWidgets) under native Wayland. For example, you can definitely do draggable widgets that dock and undock using xdg-toplevel-drag. What's changing with Wayland is that Wayland is no longer giving the developers the tools to implement features like session restore and docking/undocking entirely on their own, but instead forcing them to go through specific protocols. This is a point of contention that involves one's own ideals and unlikely to be resolved any time soon, but either way, this post is grossly misrepresenting the state of Wayland in general because of KiCad issues, that they are admitting they have no interest in triaging or working on anyways. That's fine, but it's still wrong.
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.
> Cursor/pointer warping: Essential for many CAD operations
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.
BearOso · 2h ago
When doing a fullscreen game without a visible mouse cursor, it's common to continuously warp the hidden pointer to the center and use the pointer position deltas. You could probably go lower level and use the raw device, but you end up dealing with permissions and compatibility, so it's more difficult.
jeroenhd · 2h ago
It's a UI pattern that I thought died in the 90s. When it works well, you don't notice the pattern is even there. When it doesn't, it looks janky as hell.
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.
IshKebab · 2h ago
It did die in the 90s! Apparently for everyone except Kicad (and DesignSpark PCB). I bet Eagle does it too; that's even more of a UX disaster than Kicad.
indrora · 54m ago
Most of the professional tier CAD suites do it as well.
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.
IshKebab · 1m ago
> Most of the professional tier CAD suites do it as well.
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?
phkahler · 23m ago
IMHO window positioning is the job of the DE, which will also mean a unified behavior for all apps. Unfortunately I've been waiting years for gnome to implement this.
duped · 1h ago
I've worked on CAD software in my career, and some other domains with "special" UI considerations and it's worth pointing out that this kind of commentary is dismissed and ignored by the developers of this software, because it doesn't line up with what real users of the software report or request.
varispeed · 2h ago
> Kicad has pretty awful UX
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.
duped · 3h ago
Can anyone explain succinctly why basic window management and pointer warping is absent on Wayland, what it would take to fix, and how to get involved fixing it?
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.
The historic reason is that all inputs and window manager state outside your very own window is kept secret, and "stealing" input strictly disallowed.
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.
duped · 2h ago
> The historic reason is that all inputs and window manager state outside your very own window is kept secret, and "stealing" input strictly disallowed.
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.
simcop2387 · 1h ago
> 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?
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.
cosmic_cheese · 2h ago
The balance doesn’t necessarily require that much thought or deliberation. It could be as simple as putting things like cursor control behind a permission dialog, with it being mandatory to provide a reason why the capability is needed to present in the dialog to help users make an informed decision.
jeroenhd · 2h ago
Web browsers tried that. Then spam sites started saying "press allow to prove you're not a robot". Android showed a whole list of permissions for years whenever you installed an app. Nobody ever read them, phones were full of malware, and Google started nuking APIs and replacing pre-install permission prompts with real-time permission prompts.
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.
cosmic_cheese · 2h ago
There’s some crucial differences here, though.
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.
arghwhat · 2h ago
It's actually a lot more difficult than that.
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.
cosmic_cheese · 2h ago
It’s a bit crude, but macOS handled the asynchronous prompt problem by suspending the process trying to access something it hasn’t been given permission to use until the user has acted.
amelius · 2h ago
I installed kicad on an ubuntu system using flatpak (because snap was a nightmare). But now I'm running into a strange issue with X11 cookies. Anyone who's seen the same? (Using X11 of course)
pomerange · 2h ago
Distros are not dropping Xwayland, just say "run our app trough xwayland". Recommending X11 distros or compositors is not good advice. X11 on its own is dead, and things like KDE do very little development on their X11 version.
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.
yjftsjthsd-h · 1h ago
> Distros are not dropping Xwayland, just say "run our app trough xwayland".
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.
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.
(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.
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.
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.
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_...)
[0] https://github.com/vpinball/vpinball
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
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.
IMHO window restoration is the job of the DE. Implement it once there, not in every application.
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.
>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. :)
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.
Yeah... good luck changing your protocol after it's been "staging" for 5 years and everyone has adopted it.
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.
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...
In which way was this transition the worst for you?
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.
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.
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?
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.
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.
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.
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.
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.
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
Wasn't cursor warping protocol just merged?
https://wayland.app/protocols/pointer-warp-v1