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_ 16 hours 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.
gf000 1 hours ago [-]
> 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.
Then what XWayland is?
donkeybeer 2 hours ago [-]
>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.
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.
ur-whale 6 hours ago [-]
Very apt analogy.
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.
zppln 15 hours 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 15 hours 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.
gf000 1 hours ago [-]
A window manager is just an X11-ism. It's nothing more in that parlance than a Gnome plugin.
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.
jchw 8 hours ago [-]
> They changed it so that everyone who previously just wrote a window manager now had to write an entire display server.
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.
magicalhippo 2 hours ago [-]
> 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.
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.
teleforce 7 hours ago [-]
>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.
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.
ChocolateGod 2 hours ago [-]
> X11 is a proper system and protocol
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).
gf000 1 hours ago [-]
What I don't understand is why do "GNU Linux" have such an adverse reaction to anything Android? Like why wasn't SurfaceFlinger got adapted for both?
gf000 1 hours ago [-]
There is nothing Wayland "designed out" of their system. It's a fully extendible design which has a very minimal core, instead of bundling a printer and whatnot into the display server.
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.
rcxdude 10 minutes ago [-]
The main issue is GNOME, really. They are keen to pare down the functionality offered to users and app developers, and so will block standardization of extensions that try to bring wayland up to feature parity, and even if they do get standardised, they will refuse to implement it. Which basically means many developers and users don't want to play ball with wayland at all, and the network effects are fairly strong (devs will not bother with the effort of making something work as best it can on wayland if users still happy to use X11, and users won't switch to wayland if their apps don't work or work less well).
(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)
jenadine 1 hours ago [-]
Maybe Wayland is extensible, but if the main desktop compositor (i.e. Gnome) don't implement these, it is as much as useless.
And it seems that Gnome very much "designed out" some features such as window positioning, window icon, and so on.
(We're talking about user's desktop, not custom car entertainment compositor)
LorenDB 16 hours 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.
DrillShopper 5 hours ago [-]
> vaxry (Hyprland guy)
Too bad Hyprland's community sucks
ChocolateGod 2 hours ago [-]
It's the only wayland display server to have a community.
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.
pjmlp 1 hours ago [-]
Which will only work as Windows XP Win32 is good enough for whatever people are doing, Valve is willing to sponsor the work, and Microsoft doesn't decide to do something that changes that.
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.
const_cast 10 hours ago [-]
I disagree, features are added to Wayland constantly and we're getting more and more highly supported protocols by the day. We can already do 95% of what you can do on X on major implementations - screen sharing, global hotkeys, file pickers, etc.
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.
hakfoo 6 hours ago [-]
The whole "95% support on major implementations" thing is still a hurdle. Wayland ends up railroading users into GNOME and KDE, with virtually everything else being in some way second-class.
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?
const_cast 3 hours ago [-]
GNOME and KDE are the most complete implementations, yes, but that's just a function of developer time. Keep in mind that's better than what we had with X - which had 1 implementation, that couldn't be touched with a ten foot pole because of how fragile said implementation was.
> "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.
bmacho 8 minutes ago [-]
> > "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.
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.
This kind of stuff is why I evolved from an FOSS zealot that back in the early Linux adoptions days would have email signatures with M$ stuff on it, most likely still in some Usenet archives, back to Windows land as main desktop on Windows 7.
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.
MegaDeKay 15 hours ago [-]
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.
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.
mid-kid 4 hours ago [-]
> things like multi-touch gestures are plainly broken on X11 mode in ever DE I've tried
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.
ciupicri 14 hours 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).
Just install mate or similar and ignore the drama.
superkuh 16 hours ago [-]
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 15 hours 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 16 hours 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 15 hours ago [-]
People were and are free to do so. They've chosen not to, though, so far.
ezst 8 hours ago [-]
X11 was an unmaintainable pile of legacy mess, Wayland was its exhausted developers starting from a blank slate with tons of lessons learned the hard way. It's not a cabal or a conspiracy, just a sensible evolution.
reisse 12 hours 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...
ur-whale 6 hours ago [-]
> he real problem with Wayland is that its authors and/or maintainers are *nix geeks
They also, in typical Unix geek style, don't give two fucks about what the market wants / needs.
arghwhat 15 hours 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 12 hours 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.
arghwhat 11 hours ago [-]
That's why there was a protocol released to do just that, by having the client set a unique tag when it creates its windows so the display server can recognize when a window has come back.
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.
delfinom 15 hours 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 15 hours 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 14 hours 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.
arghwhat 11 hours ago [-]
No, having bugs in home-grown platform specific code is not at all related to whether or not the platform is "weird".
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.
IshKebab 15 hours 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.
arghwhat 11 hours ago [-]
Again, not how Wayland protocol maturity works. All released protocols are versioned, and do not break existing clients. Servers offer a maximum version number for their protocols, and clients can request any version up until that maximum version. If they request an older version, the server will behave in accordance to the older specification.
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.
superkuh 15 hours 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 15 hours 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 14 hours 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.
superkuh 11 hours ago [-]
It is clear that in the article and this comment thread your claim is the opposite that of the kicad developers. Your comment attempted to make it seem like their article was in agreement with you. That was a lie you wrote rather than actually saying what you meant: that you disagreed with the kicad developers. It's hard to believe you are arguing in good faith after such a disengenous start. Especially given your wild perception of the post-fork reverts of all the code which obviously weren't spurred by code quality but instead the fork itself.
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.
varispeed 14 hours 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 13 hours 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.
ur-whale 6 hours ago [-]
So the guys responsible for the giant wreckage that is X11 are now in charge of wreckage 2.0
No wonder.
poulpy123 15 hours 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 15 hours 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?
o11c 6 hours ago [-]
I just tried out Wayland again on my last install, 1.5 years ago, because I really thought I should give it another chance since people keep saying it finally is supposed to work.
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?
DrillShopper 14 hours ago [-]
The article talks about the many open issues with Wayland that do not exist in X, if you want some examples.
const_cast 10 hours ago [-]
Sure, which are completely solved by Xwayland. If your app doesn't work under Wayland, then fine. Lots of apps don't because they're old and volatile to develop. But X11 apps work completely seamlessly under Wayland. Every major desktop right now is running many X11 apps under Wayland.
el_memorioso 10 hours ago [-]
I am a Kicad user, not just a random speculator. The problems are not solved by XWayland. For example, Kicad uses different windows to represent different views of the circuit and circuit board and warps the cursor according to the view you are looking at. XWayland doesn't solve this, because it only allows warping within a single window. I know there is new warping code coming out, but I don't know if it will ever get into the LTS OS we use at my work.
jchw 9 hours ago [-]
The obvious right choice if you're on an LTS OS where Wayland isn't in a good enough shape is to continue using X11 sessions. Very few things are dropping support for X11 right now, and on an LTS OS you presumably would be insulated from that. Obviously you can't benefit from anything Wayland improves on, but I suspect that's not a huge problem.
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.
josephcsible 5 hours ago [-]
> Obviously you can't benefit from anything Wayland improves on, but I suspect that's not a huge problem.
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.
achierius 1 hours ago [-]
You're always free to step up and support continued X development. Nobody else wants to, because the code is truly terrible, and that's been the main driver for distributions dropping support.
const_cast 8 hours ago [-]
It's such an incredibly niche use case, but nevertheless, I will retract my statement.
99.99% of stuff should work under XWayland.
msgodel 6 hours ago [-]
Xwayland has been slow and buggy in my experience. It's very far from seamless. I know one user who stuck with Gnome for decades (he was an "I don't care just get draw the stuff on the screen" kind of guy) until libreoffice became unusable because of the Wayland transition and actually switched back to FVWM over it.
bsder 6 hours ago [-]
> Sure, which are completely solved by Xwayland.
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.
ur-whale 6 hours ago [-]
> Sure, which are completely solved by 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.
const_cast 3 hours ago [-]
I think overall it's a niche feature, and I'm honestly not sure if XWayland allows X forwarding. I know it preserves pretty much all X behavior, including grabbing attention from other windows and such if you give it permission. I don't know how the implementation, specifically, works. Like if each application is under it's own X screen.
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.
jchw 9 hours ago [-]
Some of them are not really "open" issues, which is blatantly obvious if you try to drag a tab in Chrome in KDE or GNOME: The dockable widget use case is covered by xdg-toplevel-drag[1], has been implemented by multiple libraries including Qt 6, and you can fallback to normal drag'n'drop with the downside that the user can't drag the window with the handle. A new protocol was just added for pointer warping[2], too. Not going to lie and say the surface occlusion hanging GL thing isn't annoying, but it is indeed solved by using fifo-v1[3] and commit-timing-v1[4] or the equivalent stop-gap protocols that existed before those ones were merged, since not everything is there yet. Some of these problems even had some workarounds prior to the proper protocols being merged; SDL3 already had a way to warp the pointer by (ab)using the existing pointer constraints API.
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.
You seem knowledgeable in the domain, so I hope you don't mind me picking your brains about the two things stopping me switching to Wayland.
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?
mappu 4 hours ago [-]
The first google result for 'autokey wayland' is someone recommending https://espanso.org/ , that looks like it has good Wayland support. And you only need look at OBS to see screen video capture is perfectly possible on Wayland.
Who is saying those are impossible use cases? I think your two apps have just not updated, that happens often with software.
jcgl 1 hours ago [-]
There are multiple screen recorders that work under Wayland. I use Spectacle, which comes with KDE Plasma. Works well for me.
mariusor 13 hours 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 14 hours 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 15 hours ago [-]
I've been using KiCad on Wayland for years and didn't even know I was missing out
Vilian 17 hours 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 16 hours 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).
duped 15 hours 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.
josephcsible 5 hours ago [-]
> It's absolutely impossible to ask, as everyone will demand everything, claiming even the smallest feature is the foundation of all modern computing.
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.
arghwhat 17 minutes ago [-]
1. Display servers are highly security sensitive and cannot be shipped in good faith unless they are well maintained. The only high-profile X server still around, xorg, is entirely unmaintained outside its Xwayland support, and no one is willing to step up.
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.
duped 14 hours 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.
arghwhat 11 hours ago [-]
A window (surface in Wayland speak) is just an object in the Wayland protocol, and a Wayland client can have as many as it likes - it will just never see anything outside its windows. If these are normal windows (top-levels), it won't even know where the windows are relative to each other - it just receives (surface-relative) input when focused, none when not.
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.
duped 5 hours ago [-]
> If these are normal windows (top-levels), it won't even know where the windows are relative to each other - it just receives (surface-relative) input when focused, none when not.
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?
simcop2387 14 hours 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.
arghwhat 10 hours ago [-]
> 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.
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.
cosmic_cheese 15 hours 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 15 hours 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 14 hours 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 15 hours 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 14 hours 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.
> 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.
Ballas 38 minutes ago [-]
That is the first thing I turn off in Kicad (earlier versions I had to fix the source and recompile).
I have never seen a good reason for cursor warping.
jeroenhd 15 hours 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 15 hours 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.
Ballas 37 minutes ago [-]
Eagle does not do cursor warping as far as I know.
indrora 13 hours 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 12 hours 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?
indrora 8 hours ago [-]
AutoCAD historically has, as does some configurations of SolidEDGE, DraftSight.
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.
BearOso 15 hours 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.
duped 14 hours 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.
phkahler 12 hours 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.
eviks 4 hours ago [-]
> but an app should never warp my cursor. It's mine. Get your stupid hands off it.
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
varispeed 14 hours 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.
IshKebab 12 hours ago [-]
Well yeah just because the others are bad doesn't mean Kicad is good! I haven't tried Altium but I've used DesignSpark PCB, Horizon EDA, Eagle, Kicad and Geda.
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:
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.
bsder 6 hours ago [-]
> I don't know why EDA guys have this weird idea that cursor warping is totally normal.
You can't implement a circular menu without pointer warp (you can, it just sucks).
jchw 14 hours 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.
ur-whale 6 hours ago [-]
Over the many years Wayland has been promising to be a better toaster, I have tried to use it.
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.
skykooler 6 hours ago [-]
The only reason I use Wayland is display scaling - with a high DPI screen, many apps are blurry or inconsistently scaled under X11. Given the parade of other issues Wayland brings, I wish the development effort were instead spent on improving highDPI support in X11.
igor47 9 minutes ago [-]
O man I recently tried to use fractional scaling on Wayland, and it went very poorly. Electron apps like slack or signal do not support it, and flameshot also works very poorly. But I guess at least fractional scaling is to an option... (Which I had to enable in some secret setting somewhere)
Ballas 29 minutes ago [-]
In xfce, setting DPI in Appearance works perfectly (in my experience). Just don't try to scale with display settings...
pomerange 14 hours 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 14 hours 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.
- Sent from my laptop running Xorg
const_cast 10 hours ago [-]
X11 works as well as it ever did, but it's so stagnated that that doesn't mean a whole lot. I run new hardware, and I tried X. It's bad. HDR? No. Fractional scaling? Looks awful. Splitting, tearing, and artifacts? Believe it or not, still a problem on X.
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!
yjftsjthsd-h 4 hours ago [-]
I dunno, I'd say it goes both ways. I'm still on X because last time I tried Wayland still had weird janky corners that I kept hitting. Granted, yes, X also has problems, so I'm stuck in an awkward intermediate spot.
And again, in the year of the lord 2025, the year of linux on the desktop is next year.
amelius 15 hours 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)
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.
Then what XWayland is?
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.
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.
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.
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.
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.
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).
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.
(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)
(We're talking about user's desktop, not custom car entertainment compositor)
Too bad Hyprland's community sucks
Also see this thread where Vaxry lays out his gripes with Freedesktop.org: https://xcancel.com/vaxryy/status/1934721645115224431
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.
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.
[0] : https://www.google.com/search?q=ubuntu+adwaita+dark
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.
[0] https://github.com/vpinball/vpinball
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 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.
> 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_...)
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
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.
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.
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.
>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.
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.
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.
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.
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.
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.
In which way was this transition the worst for you?
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?
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.
99.99% of stuff should work under XWayland.
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.
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.
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
[3]: https://wayland.app/protocols/fifo-v1
[4]: https://wayland.app/protocols/commit-timing-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.
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.
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.
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.
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.
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?
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.
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.
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.
I have never seen a good reason for cursor warping.
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.
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
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).
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.
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.
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!
Wasn't cursor warping protocol just merged?
https://wayland.app/protocols/pointer-warp-v1