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.
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?).
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.
This just false. There are libraries you can use to get most what you need and you can only change the things you care about related to window manager. And many systems have done that. Libraries are somehow a good way to share software, but not when it comes to display managers?
The claim about OpenSource manpower is also false. We have multiple high quality compositors and despite any issues, there is quite a large amount of homebrew and other compositors.
If you want something like X11, you can built on something like Mir.
The point is: The libraries are not from the same people that build the standards, meaning: there is no "primary implementation" that everyone agreed on. ("agreed on" already is one of the problems, X11 was mostly just developed and everyone got "the thing" and had to use it, for better or worse. In Wayland, KDE, Gnome, wlroots, etcpp first have to agree on a common protocol to implement... and we see how that is going)
Besides there being a large overlap between the "people that write the standards" and library authors, how is there no primary implementation and why does it matter? It's literally an XML document that can be used to generate C code for the server/client, that can communicate via a binary protocol.
This is just a faulty sentence. If you meant that there is no general consensus on which extensions are "core core" and which are completely optional, that might be a more reasonable criticism.
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.
Emphasis on the plural in "toolkits", X has one standard interface running on people's computers that window managers target. X environments end up having common behavior regardless of window manager, and for application developers having to target each Wayland display server with its own subset of protocols has to be less appealing. That is what that comment was getting at.
Application developers don't want to log your keyboard and aren't oblivious to security. The lack of a standard Wayland display server is a real grievance.
Where is that common behavior, is that GNOME's one, KDE' one, or the million tiny window managers' ones?
Would you swear that no "application" developer would want to log my keyboard if we include the transitive dependencies of every single nodejs/python/etc package that I use for regular-ass development? Because we have seen how trustworthy supply-chains are. But sure, you can definitely drive a car without a seatbelt on, it's just not a good idea.
> 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.
> 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.
Well, with systems that's actually the case. It's suite of mostly loosely coupled tools and services and you totally can swap out or disable many of the components however you like.
They mostly just use DBus and/or Varlink for IPC and use some common shared libraries to prevent code duplication across the whole project.
well, no? Systemd actually also delivered all of the implementations of those protocols and barely no one cared to fit their previous solution to their standards? Rather, it was the opposite, systemd could also run your usual service shell scripts for a while.
Sure, there are similarities in the sense that you started out with 0 service files at the beginning and no GUI toolkit implemented the Wayland protocol from the start, but the thing itself is pretty different. Systemd wasn't designed by committee (and many people still have gripes about this). Wayland kinda is.
The "choice" people want is the ability to easily mix and match a patchwork quilt of software from different parties, each adding one tiny behavior. Wayland doesn't do that: it makes it so almost every behavior people want must be added to the compositor.
The magic is in finding what the right point in the abstraction is: what will be centralized and what will be decentralized. Both of your examples--systems and Wayland--made the same decision: the patchwork quilt of behaviors was complex for many users to get working, and even then often didn't work 100% always. It was also slow and a bit insecure (if you don't trust your software).
So, both systemd and Wayland took the same approach of pushing forward the boundary of abstraction and merging together most of the things people would have had to configure. This means that that one core component in the middle -- and sure: in Wayland you can have multiple implementations, and those can even share a library, but you can't MIX AND MATCH -- must do all of the things people want.
The reality is that no one wanted to maintain multiple X11 servers... but we also didn't want to! What we do want is to to be able to mix and match compositors and macro systems and window managers and all of the fun little behaviors that make a computer feel like it works for us, and now we can't, as we have to find and select a single giant ball of behaviors that happens to be close enough to what we wanted.
Theoretically, some day, someone could make a really advanced and capable display server for Wayland, one that will be extremely general and will have a number of protocols for how to extend its behavior. It will be the one display server to rule all display servers, and even ecosystems like Gnome and KDE could just interoperate with it, and we could get back the glorious ecosystem that people are killing...
...but that's effectively what X11 is, right now, and by the time you get that--with a ton of protocols that are old enough to be widely used--all of those behaviors will have aged and ossified and the code will be built by people who are gone in a language that isn't fun using conventions that are out of date, and some A-hole will point out that the stack is difficult to maintain and user's experience is variable and throw the entire thing out to start over :/.
Like, I dunno... I honestly do not understand how you are saying Wayland is doing the thing people wanted from systemd: the issue isn't that I wanted to be able to replace systemd, the issue is that I wanted systemd to not be a single giant C program because I really liked the patchwork of scripts and behaviors and alternative parts that were built up in the ecosystem.
And again: everything tends to end up with some central thing in the design somewhere... but you have to make that thing be so boring that no one has any interest in innovating on it, and X11 was that: while I do think we should have multiple implementations for robustness, we would expect every one of those implementations to work as close as possible to 100% identically.
Well really, what people actually want, by my estimation, is a machine that works and to not have to adjust their workflows. These are both very sensible things that everyone understands. The stuff about "UNIX philosophy" and composability is mostly BS. We're talking about Linux, the least UNIX-y UNIX-like imaginable. People getting mad that a single program does too many things is insane when the first thing your computer boots out of firmware is the Linux kernel. Same for many of the more ideological systemd complaints, some of which exacerbated by people not understanding that systemd is an umbrella project and not an init daemon (and you can in fact swap in and out many of the components like timesyncd, networkd, resolved etc.)
I think whether Wayland really was what people wanted out of systemd or not is mostly not that important. I'm arguing that people were mad because systemd took away their choices, you're arguing that Wayland wasn't the choices they wanted. I'm not sure what choices they wanted. I don't think most people who are mad about new things have fully-formed opinions about what they actually want in the first place. Either way, Wayland gives you nothing if not plenty of choices, and many of them much more complete than what you could get with random WMs on X.
Most importantly, though, I strongly disagree that X11 is the ideal protocol to build on. X11 is a mess that's hard to implement and if you omit anything you'll basically always break a non-trivial amount of software. XInput 1 is pretty broken but tough, Wine needs it. Have fun implementing Xv everywhere too, and XRender. Most modern apps just grab a GL or Vulkan context and ignore all of that, but if you want to meaningfully implement X11 those things need to be there. I could go on, but I'm sure you get the point.
Realistically, I'm sure we don't want to maintain multiple X servers. As it is, nobody wants to really maintain X.org to begin with... Well, there is one guy, but that doesn't appear to have gone so well so far.
What's funny is, when people actually want to have X11 support, what they do instead is implement Wayland and use XWayland instead. Seriously, look at how many things implement Wayland: ChromeOS for Linux apps, SteamOS for game compositing, Windows for wslG, termux-x11... Wayland and Weston are much easier to implement and adapt than X11 and X.org were.
When everything works well across all of the GPU vendors and the major applications have the remaining kinks ironed out, things will keep moving along and the sky will probably not fall. I honestly think that people were going to get cranky even if everything was done absolutely perfectly here, because succeeding X requires some people to do a bunch of work and adjust their workflows. Don't blame 'em, doesn't mean they're right.
>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.
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).
>Things like HDR, multiple refresh rates, mixed DPI, passive compositing, hardware planes are just harder to do.
Are you sure it's easier to do with Wayland, all this while the Linux HDR is not working well [1],[2].
I've got the feeling that every features claimed to be easier with Wayland are all bogus and the same thing can be achieved with the same amount of effort and time on X. Wayland now really feel like the Emperor's New Cloth.
[1] Ubuntu 25.04 & Fedora 42 Hit A Long Sought Milestone With HDR Support Working Well On The Linux Desktop:
> it's designed for drawing on remote terminals over a network
Yes, but.
On a local machine the "network" is just system calls, and the kernel just hands the data from one process to the other. The overhead is minimal. HDR, multiple refresh rates, mixed DPI, these can all be implemented on the existing protocol. X11 actually closely resembles win32 (it was inspired by the same source after all - Xerox Parc GUI research), which has support for all of these things (it may not be pretty but are Adobe or the legion of game devs complaining? Of course not, it's write once and done.)
> Like why wasn't SurfaceFlinger got adapted for both
IIRC SurfaceFlinger is tightly tied to Binder which is an Android only kernel IPC, didn't work with the standard Mesa stack and wasn't designed for multiple windows with multiple displays.
Wouldn't be surprised though if eventually Android swaps to Wayland as Google wants to merge it with ChromeOS. Since talking to the compositor is abstracted away to the platform APIs, I don't see it as big of a hurdle as X11 to Wayland was.
Adopting SurfaceFlinger on the desktop would certainly be a step backwards, OEMs effectively fork it each time and change it for functionality on their devices.
Google sometimes tries to add these features (e.g. split screen, multiple windows etc) into the base code but can take time for OEMs to adopt them on their skins.
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.
> 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.
>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.
I counter with Pipewire. Supports all of the previous linux audio systems out of the box, and almost right from the start (and is drop-in replacable), has less bugs, less problems than their previous options. Runs stable as hell.
Sometimes I wonder how this even happened, like, it seems impossible.
It was done by someone who deeply understands the subject matter and it took a couple of years of full-time work before seeing wide use. But yeah, it's so good that you can basically put a checkmark on "Linux audio".
Wayland isn't bad or limited by design. It's just too little. If you just made all the necessary extensions for desktop use and made them mandatory (possibly in a single implementation like Xorg), you'd have a solution.
Sure it's a problem, but more of a social one. Wayland's creator was weirdly opposed (that was the net effect anyway) to adding features, and the freedestop.org setup is better, but not good.
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.
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?
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.
> > "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.
And I agree, I don't see how could've been this a killer application for Wayland, this should be accomplished with distributing config files, and not somewhere near the display protocol.
The landscape was quite different in 2014. I know, I was there, and Linux desktops have been getting less themable since because application technologies are going off the rails.
KDE today is still fairly themable if you stick to Qt apps and GTK 3 apps. But if you use a dozen frameworks then yeah, that's not themable anymore. Which really sucks but it is what it is. And, honestly, it's not that bad. It's much, much worse on some other platforms.
> It does astonish me how Wayland missed obvious killer angles when they decided to reinvent X11. [..] rich native toolkit
What does a toolkit have to do with a display server?! Especially in this age and year when pretty much no one writes native UIs anymore? Like, android, which is by far the most popular OS by user count has a huge proportion of web apps - apps are fundamentally driven by network effects, so the tiny user count a new Linux contender could muster up would be a rounding error.
If you asked people "what are your pain points with the current Unix GUI ecosystem?", in the early 2000s when this was being first discussed, this would have been a popular answer.
This was decades before the "let's make everything a stupid webpage in an Electron box" movement, but you were likely running some GTK and Qt apps and probably even some Motif or Xaw stragglers, on a single desktop most days.
Yes, they could have said "out of scope" and moved on. TBH, I wonder if that's part of how we ended up where we are. There probably needed to be clear documentation at the right moments of "this is what we don't include, this is why, and this is how we recommend you do it outside the system."
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.
Why does it suck? I run hyprland but I'm not really involves with the community. The times I did have contact they were helpful and super quick with solutions. Like literally the issue is fixed in a day.
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.
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.
Yeah you've got a point. What's the lesser evil though when the alternative is overconfident over-motivated junior devs refactoring stuff for the sake of it while breaking apps, not realising their work should be to support the precious few FOSS desktop apps we have that won't come back with no new ones in sight either, leading us into know how monopolisation. That attitude is showing right here with Wayland apologists getting defensive as in nothing wrong with Wayland, it's just a new "platform" lol. Same thing with programming language fetishists which is just a means to an end. The problem is that the next generation of developers want to have their fun and educational experience reinventing stuff, too; and who wants to blame them when that's just what the previous gen did.
This is just malicious, ignorant and plain falss towards the Wayland developers (which is by the way a very diverse group), whom are by all chance waay more experienced than you are.
Also, fails to take into account that X has plenty of objective design failures, which is to be expected given GPUs didn't exist at the time of its invention.
Amiga 500 Blitter, which is a baby step into GPU would become, is from 1987.
Texas Instruments TMS34010 was released in 1986, being the very first programmable graphics processor, going beyond DMA programable ones like the Amiga 500's Agnus.
While these jurassic GPUs could not be taken into account for X Window 1.0 design, by the time of X11R6 release, it was more than enough time to have had them into account.
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.
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)
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)
Its similar to the CVS analogy given below, however I would liken it to Pulse Audio. We know we have needed to "fix" the audio subsystems for a while, and Pulse fixed a lot of problems but by the time it came along what were problems had moved on. Pulse ended up with other issues, and not actually doing everything we actually needed so it was eventually replaced with Pipewire.
I'm not sure if Systemd falls enough into the same pattern, but I'm sure something better will emerge in the next few years.
The more I dig into systemd the more I like how it works. Are there still problems popping up with systemd? Anecdotally, I had a couple user-facing problems that were caused by PulseAudio but never systemd actually being broken.
It won't be win32 because it just isn't on Linux and there is no reason for it to be.
Wheres game compatibility is great with proton in between apps are not with installation sucking, mostly replicating better native apps, and updated versions which are common and continuous in apps as it isn't in games usually leading to breakage.
I don't know about that. I've always been skeptical of the "X11 can't be fixed" claims, nobody has ever been able to explain that one technically, it's always "I read it somewhere" or "Trust me bro the code is bad (and I read that somewhere)". With XLibre, maybe there's life left in X11.
Wayland devs and Xorg X11 devs are by and large the same group of people. So nothing you said really makes a lot of sense.
There are lots of display technologies out there for Linux besides X11 and Wayland.
There was Mir from Canoncial, which is now dead. The project moved to using Wayland.
There was Freon from Google's ChromeOS that was announced in 2015 to replace X11 for ChromeOS, but it is dead. They are moving to using Wayland.
There was DirectFB, which has been supplanted by DirectFB2. They have been plugging away doing their own thing since time immemorial. Directfb2 even has Vulkan support now. Good luck getting KiCAD working on that.
And there is Surfaceflinger from Android. Which is actively developed and widely used.
None of these things would allow to do what people are complaining about what they are not allowed to do in Wayland .
> There's too many things people want to do that Wayland designed out of their system.
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.
> The X.Org server, an implementation of the X Window System, was previously deprecated and is removed from RHEL 10. Note that the X11 protocol is not removed, which means that most applications will remain compatible through the Xwayland compositor. For more information, see Red Hat Enterprise Linux 10 plans for Wayland and Xorg server (Red Hat Blog).
Wayland messes up Visual Pinball as well [0]. VP depends on being able to place the main playfield window, the backglass window, and the Dot Matrix Display window in specific locations on specific monitors mounted in the cabinet.
The fact you have to edit a config file means it's missing the boat by mile. A user should not have to learn config file formats in a graphical GUI interface.
<app> should not require user to <insert skill>. <app> should be permitted to do reasonable things without requiring user to come up with workarounds for missing functionality.
With X11, neither the application nor the user requires a window manager to place the window at all. The application can just put itself where it wants, even with no running window manager. That's the point.
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.
> I've developed cross-platform applications and it was enough work without the extra headache they describe Wayland brings.
Have you tried wayland-client? When I made my custom application framework, since I had no previous experience I decided to start with wayland-client library, and then figure out what to use for X11.
My experience with it is that it is painfully sensible. Things fail when misused, which happens a lot (probably also because only few people actually wrote code with it so I was on my own to understand how to do stuff), but at the end they were fixable, and the only gripes I had were the protocols that GNOME didn't implement at the time. But I guess, if they are not implementing it right now, it means that they think it's okay if it does not work. (and actually I could also defend a lot of missing things in Wayland protocols, like the fact you can't position windows yourself)
On the other side, X11 just looks like a mess. When you start it feels like you have 2 options, XCB and Xlib. Old posts say that XCB is the modern one, but nobody uses XCB so in fact you may encounter bugs. Error handling is really poor, most of the errors are small messages written in stdout. You ask for things called "Atoms", and you send them/attach them to the X window. No feedback on whether it works or not, they mostly have weird names with prefixes like _NET_WM or _MOTIF. If you want to make an OpenGL window, for a long time it was not possible if you used XCB because GLX requires you to give Xlib handles, then came EGL-XCB which was supported by almost no driver because for some reason it seems that you need driver support for each X library you may want to use. When you start you're reminded of a slew of somewhat niche concepts today, like Visuals, Seat, Back pixel, Front pixel, which you are probably not expected to use today (in detail, I know, visuals may be useful in some small use cases, I don't know why the app is in charge of selecting the seat though, and pixel stuff is probably a dead thing). At the end the only thing that makes X11 bearable in my opinion is the fact that people wrote a lot of code with it so you can search on the Internet for the most part and find a snippet of code that should work for your use case.
To get past this, you have to learn that X11 is a protocol, not a library, and learn the protocol and then use the library to send protocol messages, instead of learning the library, which is how it's unfortunately taught and also how Xlib was unfortunately conceived of being used. Xlib was designed so you'd use it similarly to say Win32; that idea was a colossal failure. xcb is more closely aligned with the idea that it just helps you format network packets.
I am holding on to xorg until i can shade Windows and use something with half the power of xinput to configure my trackball. Oh, and I also want to be able to have many different keyboard layouts for sddm. Most themes fail to display a layout selection menu that isn't blank for me.
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.
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
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
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.
It's a pattern that I have seen a few times before, "I know! We will do the exact opposite of the problems with the previous project!" - but that's not ideal neither.
I don't have a horse in this race, but I also can't blame the Wayland designers for not rushing to implement something like that. Encouraging application developers to manipulate windows themselves essentially means turning them into window-manager developers, but with a hand tied in their back and probably little interest in doing it thoroughly. I think the practical results speak for themselves: I cannot count a single application that does it extensively and that isn't broken in the typical multi-monitor cases you find in the wild.
Well, in Wayland, the same apps just don't work at all. The developer basically has to rewrite them and turn them into different apps to make them work in Wayland. Is that good or bad? Maybe if you hate a certain type of app it's good, but this is the open source world and if something doesn't hurt anyone then you should probably be allowed to do it. It's not the display server's job to rule by fiat. It might be the window manager's job, but only if the application-provided coordinates don't work, or you're using something strict like a tiling WM.
> The developer basically has to rewrite them and turn them into different apps to make them work in Wayland. Is that good or bad? Maybe if you hate a certain type of app it's good
Just to make the record straight, it's not about "hating" anybody or anything. And I really don't see the need to appeal to emotions here.
It is about acknowledging that this way of doing things might, in retrospect, have been a bad idea all along and represents a technical dead-end. Departing from it, given the chance, is for the benefit of all in the long run (tech doesn't like carrying old bags around forever, and I suspect that your laptop don't hold a CD-ROM drive for similar reasons).
> if something doesn't hurt anyone then you should probably be allowed to do it
It would cost the Wayland compositors developers extra effort to maintain this capability for decades to come, it's not free. Moreover, those apps would still be broken by design (not in a position to do as good a job at positioning their windows as the compositors would do), so the compositors developers would, as a second order of annoyance, probably see their issue trackers filling-up with user complaints that are outside of their scope/power to address.
> this is the open source world
And the great news here is that those entrenched apps who refuse to adopt more modern UX paradigms (for the detriment of their old and new users alike, if I might say) will still be able to run through XWayland virtually forever.
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...
I have a better one: They designed for embedded devices first, desktops second or not at all. The first users of Wayland were things like vehicle infotainment systems, which operate under a limited mobile-like "one app at a time" system. Back then Ubuntu Touch (using Canonical's Mir) also looked like a prospective usecase for a new display system.
As far as I remember, the Wayland devs' approach to desktop support was "we made the basic protocol, now you desktop people either integrate functionality into the compositor (what GNOME did) or make your own extensions (what wlroots, KDE did), we don't care". With that kind of "leadership", no wonder it took years to reach even basic consensus.
Even if they did (which is questionable for me, because although a lot of embedded did jump to Wayland pretty fast, the maintaners never stated their goal is any less than replacing the whole X), they had a lot of time to pivot and rethink the design. I believe the general consensus that Wayland is the future of Linux on desktop was formed in 2013-2014, yet the feature gaps are still being patched.
Yeah I don’t know any of the details but KiCad is a pretty serious engineering gui tool and I find it easy to believe that the Wayland devs would exclude those uses cases from their designs
Quite the opposite. Wayland&Gnome are designed for tablets, phones, and barely laptops. Any usability on Desktop/Workstations is pure accident. Consider even the login screen-- it does nothing unless you do a completely inexplicable (on a mouse) click and swipe up.
As your theoretical "*nix geek" who mostly uses terminal windows, wayland and gnome provide an inferior experience to the daily driver software of 20 years ago.
At least some of them were people trying to hack X.Org to deliver an 'iPhone-like' experience on Nokia Maemo/MeeGo devices. The Jolla phone ended up being the first consumer device to ship with Wayland afaik.
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.
>> 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.
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.
>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.
> 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.)
The Wayland developers also include major toolkit authors, and a bunch of them contribute far and wide.
But, to most users, switching to Wayland just means that everything got smoother, and easier ot use, with everything working. Even X11 applications will work just fine. Even if Wayland has an omission that is greatly upsetting to an individual, the X11 mode of the app will usually work exactly like it always have without leaving the Wayland server. Anyone using extremes like "unusable" (or "perfect"!) is not providing meaningful information and can safely be ignored.
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.
Editing a comment for clarification is not bad faith. It avoids misunderstanding and helps those reading it, even if some have already read an earlier version of it. It makes it sound as if you consider comments a battle, with changes being cheating or foul play, which... Is just wrong.
Nothing about my comment was bad faith or disengenious, nor did I say that I agreed with KiCad developers. I just said that, and will stand by, that it is erroneous to read their claims of e.g. performance issues when using their wayland platform code as being an issue with Wayland. If you write new code that is slow, you don't start by blaming your CPU, then your compiler, then your OS, and Wayland is generally known to perform better than X11 by virtue of being designed by people also working on the GPU driver stack.
Editing minor bits like typos, or changing some wording isn't, but completely changing your comment an ~hour later after multiple is. And I get the feeling you know that. You're obviously a smart, capable person. I don't buy the confusion.
Where did your ">it's easy for others to read this and conflate "problems with application's Wayland support" as "problems with Wayland"." go? That falsehood started this particular comment thread and everything it's about.
That statement is both still there in its entirely unchanged form, and still entirely true - quoting the comment as it appears on my screen right now, long after any edit window closed:
> but it's easy for others to read this and conflate "problems with application's Wayland support" as "problems with Wayland"
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 ;)
> 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 ;)
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.
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.
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.
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)
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?
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.
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.
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.
> 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.
That seems like a solved problem though. LTS distros will drop X11 when the Wayland session is viable for most people, which is very nearly true, but ultimately not. When it does happen, it really shouldn't come as a sudden surprise.
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.
Arch will presumably pick up GNOME 49 as soon as it's released, and so GNOME on Arch will also drop X11 session support this (northern hemisphere) autumn.
I know that most Ubuntu users run LTS versions, but still, those are probably the 3 most widely-used Linux distros in the Western world, and as such, I think the statement that "very few" things is false where it applies to Linux distros.
When I said that, I meant applications and UI toolkits are not dropping X11 support. Non-LTS OSes will definitely be dropping X11 support pretty soon, since yes, KDE and GNOME are both throwing in the towel. To me the timeline seems about right for that too.
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.
That's not the fault of Wayland, it's a GNOME problem. Wayland being just a protocol has the annoying effect that you get DE-specific bugs. It also means that after switching DEs, you might escape some GNOME-specific bugs.
I've been happily using KiCad under XWayland on Sway, I've had no complaints from relatives about the stability of KDE under Wayland, and I hear Hyprland is nice too.
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.
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.
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.
The performance is worse but the seamlessness of just using SSH to launch a remote app on the local display is incredibly useful when working on headless servers over LAN. Drastically more useful than having to start an entire windowed X11rdp session to run one app for five minutes
See my comments about Wayland team not listening to their users.
It is probably a niche feature FOR THEM.
Now, I most certainly agree that X over network is horribly inefficient.
However:
1. RDP is a freaking mess on Linux. It may be much better at the protocol level, but all the clients are horrible, and it misbehaves horribly across WANs and/or firewalls. And setting the whole fucking thing up is certainly *way* harder than typing the casual one-liner "export DISPLAY=<ip>:0; firefox&"
2. There is therefore no alternative to X11-over-the-net, and in this 21st century world of everything-in-the-browser enshitification, having to use X11 over the network is something I hit and absolutely rely on about once a week when configuring remote servers.
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?
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.
It's not impossible, but it requires extensions to the protocol. Historically the main headache is that support across different compositors was inconsistent, and may not even use the same extension, which means a developer looking make such a tool would need to in practice need to implement many different interfaces to make it work, which tended to mean it didn't happen (I think most devs kinda get as far as looking at the interfaces, seeing a bunch of drama between different compositors about what the correct way to do it is and whether it should even be done at all (GNOME), then decide to go for a nice walk instead). I think screen recording is now reasonably well supported and standard, I don't know about input interception and simulation.
The quick answer is that Wayland, while it has certain design provisions for privacy and security, doesn't really enforce anything on its own, it's just a set of protocols that applications can use to talk to a display server. The display server is free to do whatever it wants. Unfortunately this is poorly understood due to it being generally poorly explained.
I'll start with screen capture because it is easier. This one can be done on basically any Wayland compositor by using desktop portals + Pipewire, with the downside that applications must ask permission before they can capture the screen or a window. On KDE, XWayland apps can also capture the screen or a window, but it will also require a permission prompt. On some wlroots-based compositors, there are special protocols that allow Wayland clients to see other Wayland top-level windows and capture their contents directly without any permission prompts; for example, with OBS you can use the wlrobs plugin.
In fact, screen capture in OBS will be more efficient than it was in X11, as it will work by passing window buffers through dma-bufs, allowing zero-copy, just like gpu-screen-recorder on X11. OBS is a bit overkill for screen recording, but I still recommend it as it's a very versatile tool that I think most people wouldn't regret having around.
Now for Autokey. This one is possible to do, but I'm not 100% sure what the options are yet. Programmatically typing is certainly possible in a variety of ways; wlroots provides virtual input protocols, and there are other provisions for accessibility tools and etc. However it seems right now the main approach people have taken is to use something like ydotool which uses uinput to inject input events at the kernel level. It's a bit overkill but it definitely will bypass any security in your Wayland compositor :)
The more proper way to support this sort of use case would actually be by interjecting yourself into the input method somewhere. I don't know if anyone has done this, but someone DID try another route, which is to implement it on top of accessibility technology. I haven't tried it so YMMV, but I believe this is relatively close to what you are looking for.
Though, it has the caveat that it only works with applications that properly support accessibility technology (I would hope most of them...)
> why isn't there a "user root" level for apps that do need to interact with other apps?
Truth told, Wayland being inherently capabilities based, all of that could be implemented. Wlroots implements all of the protocols you'd imagine would be in that group, but it's just passively available to all applications by default. (I think they may support lower privilege applications now, too; there's protocols that convey security context and etc. for sandboxed apps.) The wlroots protocols are very useful, so they're also being implemented elsewhere.
If you wanted you could grant just as much capabilities to a Wayland app as before, and give apps the ability to interpose themselves between everything else, get and set absolute window positions, etc. it's all up to the compositors. Personally I think over time we'll see more provisions for this since it is useful even if it's not needed 99% of the time. Just don't expect too much stuff to work well on GNOME, they can be... challenging.
> The quick answer is that Wayland, while it has certain design provisions for privacy and security, doesn't really enforce anything on its own, it's just a set of protocols that applications can use to talk to a display server. The display server is free to do whatever it wants.
I love having to detect at runtime the compositor I'm using (and its version) and have bespoke code paths to work around their various bugs and omissions.
Definitely a recipe for reliable, usable, maintainable software.
> Unfortunately this is poorly understood due to it being generally poorly explained.
This reads like a "missing missing reason"[1]. People do understand it, and they explain why it's a dealbreaker. Wayland has had a decade and a half to grow some consensus and make these very basic things that work under X11 work. Instead of doing that, they're now relying on the main distributions just giving up on (the hardware) X11 servers instead of fixing this. I don't care if only one or two compositors that I don't run support the one thing that I need. That doesn't help me because those compositors don't implement other functionality I need. Having a stable, agreed upon, universally consistently implemented base of functionality that application developers and toolkits can rely on is a good thing.
This is a complete clusterfuck, and that's why there's user feedback. Trying to frame it as "people just don't understand" isn't productive. They do, and their criticisms have some validity. It's up to the Wayland devs to see if they care, and historically, they haven't.
> I love having to detect at runtime the compositor I'm using (and its version) and have bespoke code paths to work around their various bugs and omissions.
> Definitely a recipe for reliable, usable, maintainable software.
Honestly, tough. I didn't like dealing with Xlib/xcb, the weird error handling, or broken ICCCM implementations, but all of that stuff is typically lower level than most developers need to care about, since most developers are going to be using toolkits. If you need or want to go lower level, Wayland is what you get now. You don't have to do anything, you can always take your stuff and go home; the free desktop, though, is not going to be moving back towards X11. The rest of us will keep working to improve Wayland until it stops hurting.
Modern users have high DPI displays, variable refresh rates, multiple monitors, and panels with HDR color space support. X11 was just never going to work well for this. KDE Plasma 6.3, on the other hand, handles any of these situations quite well and I've been using it on a daily basis.
There are many users who can't even do real work without proper color management; it's so bad that for Blackmagic users the typical workaround is additional hardware. Retrofitting good color management into X11 is just not something anyone wants to try to do, it's not fit for the task. We have to move on, and Wayland is the best path forward for the foreseeable future.
> This reads like a "missing missing reason"[1]. People do understand it, and they explain why it's a dealbreaker. Wayland has had a decade and a half to grow some consensus and make these very basic things that work under X11 work. Instead of doing that, they're now relying on the main distributions just giving up on (the hardware) X11 servers instead of fixing this. I don't care if only one or two compositors that I don't run support the one thing that I need. That doesn't help me because those compositors don't implement other functionality I need. Having a stable, agreed upon, universally consistently implemented base of functionality that application developers and toolkits can rely on is a good thing.
Not a big fan of people throwing out psychology terms half-heartedly, but whatever.
The key misunderstanding is thinking that Wayland stops you from doing anything, but really from an end user's standpoint, the right question is "Can I do x on KDE?" because it is your compositor that really defines what your desktop is capable of in the Wayland world.
Developers have to deal with fragmentation by design. Wayland is not a superset or subset of X11, it's an entirely different thing altogether that happens to also cover the use case of applications talking to a display server. It also covers things like kiosks and embedded systems that X11 could be jammed into but was never a great fit for. Technically you're not guaranteed xdg-shell but that never seems to bother anyone.
This is not an accident at all though, it's an intentional strategic choice. Giving application developers less low level tools was a logical choice when looking at the types of hacks X11 applications did to implement features the desktops did not nominally support. This acts as a forcing function to have desktop systems properly support features that they need so that these features can properly integrate into the system. There's no equivalent to layer-shell in X11.
It is not expected to be a thing application developers are always happy about. People are rarely happy when agency is taken away from them.
> This is a complete clusterfuck, and that's why there's user feedback. Trying to frame it as "people just don't understand" isn't productive. They do, and their criticisms have some validity. It's up to the Wayland devs to see if they care, and historically, they haven't.
This was not a response to user feedback, it was a response to a question that revealed a misunderstanding. It's just that simple.
> Wayland is not a superset or subset of X11, it's an entirely different thing altogether that happens to also cover the use case of applications talking to a display server.
This is the core issue, it seems. The Wayland transition is kinda like if Volkswagen said "we're now going to stop making cars, and focus entirely on making the best gearbox possible". Well what are people that just want to get around going to do?
> Developers have to deal with fragmentation by design. [...] This is not an accident at all though, it's an intentional strategic choice.
And this is what I referred to in my original post, when I said that I think this decision was a very poor decision. People developing applications have enough on their plate, they don't need more fragmentation to contend with. Especially cross-platform application developers. I know, I've been one.
In my view it would have been much better if Wayland had sought to reduce fragmentation of the Linux desktop. Instead it seems the Wayland developers decided to turn fragmentation up to 11 by just implementing a minimal core set of protocols and let the DE folks figure out the rest for themselves, and application developers deal with the fallout of that.
At least that's how it looks from the sidelines. On Linux I'm just a user that wants the applications I want to use to work. I've been running a Linux desktop as a secondary machine for two decades now, and based on that experience my feeling is that it robbed at least 10 years of development from the community.
I get that X11 just didn't have a future, but to me it seems the choices the Wayland developers made meant the replacement happened much slower than it could have. That is, we could have had a much better Linux desktop today than we do, had they made different choices.
Alas, we'll never find out. Meanwhile my primary desktop remains Windows, at least for another 5 or so years. Perhaps the Wayland-based desktop is ready then.
> This is the core issue, it seems. The Wayland transition is kinda like if Volkswagen said "we're now going to stop making cars, and focus entirely on making the best gearbox possible". Well what are people that just want to get around going to do?
Even if it is a bit annoying, this pain is a temporary one. Users didn't really need to know what an X server is or how to use it, and likewise they don't really need to know what Wayland is... except for one thing, which is during this transition they need to know what the trade-offs are for "GNOME X11 Session" vs "GNOME Wayland Session" and so forth. But otherwise, neither of these things were meant to be marketed to end users in the first place. Unfortunately though, user's intuition is failing them: There is a much bigger difference between "GNOME Wayland Session" and "Plasma Wayland Session" than there is between "GNOME X11 Session" and "Plasma X11 Session", and it's not clear or obvious at all.
> I get that X11 just didn't have a future, but to me it seems the choices the Wayland developers made meant the replacement happened much slower than it could have. That is, we could have had a much better Linux desktop today than we do, had they made different choices.
To be honest, I don't know the answers. I think a lot of people see me routinely defending Wayland and think the reason is because I personally think it's wonderful, but actually I think Wayland is ugly and made many bad decisions. The wire protocol has no native 64-bit integers. I think that the GNOME folks are dumb for not accepting server-side decorations as a reality and figuring out how to make Mutter handle it, even if it involved working out out-of-process stuff for it. Trying to deal with the GTK/GNOME developers for trying to work on a problem was so frustrating I flat-out deleted my GNOME GitLab account. I also think that it is unfortunate that we already have a fair amount of cruft in the form of unstable, staging, ext, etc. protocols that are sometimes available and sometimes not. Even with all of that in mind, it's so blatantly obvious to me that Wayland is the future for Linux, at least right now. There's no better option emerging, and frankly there are no true deal-breakers with Wayland... Just challenges.
Admittedly, part of the reason why the case for Wayland feels relatively weak now is just because the X.org server got a lot more usable in the last decade or two. When I first jumped on Linux, the X11 server we used was XFree86. There was no hotplugging; if you wanted a new monitor or keyboard to work, you had to restart the X server. Once hotplugging was added, it was unstable for a long time and pretty routine for plugging in a monitor to crash. Multi-GPU situations are still pretty hackish though they do sort of work. In 2013, X11 worked on touchscreens, but it was extremely unstable, and it wasn't uncommon for things to get "stuck", or the X server to simply segfault when touching the screen. Until 2021, variable refresh rate was basically unusable for multi-head configurations, since the primary head drove the buffer flipping. The Linux graphics stack improvements with DRM and KMS became a part of the X11 experience, as did the work done on libinput to improve touchscreens and pen tablets. It worked so well that many people wonder, why not just keep doing X11 then?
I just think there's no future in it. It's not that it's physically impossible; obviously, Microsoft is able to make all of its old systems cope reasonably well with a modern desktop compositing system, including complex things like DPI virtualization. It's not literally impossible for X11 servers to fix these problems. But the thing about a lot of those improvements, including the improvements to DRM, KMS and libinput, were investments in the future and backporting them to X.org helped improve them quite a lot. Trying to retrofit something like DPI virtualization or color management into X11 would be a massive unthinkable time investment that would mostly be in service of a protocol and codebase that already felt dated by the late 90s. It took years just to make a good color management protocol for Wayland where it's actually something that slots well into the design! And it's not just "ha ha wayland developers dumb", the thread is huge and sprawling with legitimate concerns mostly surrounding how to do color management right. Spending that time on X.org just feels like it's a waste. If you try to clean up the unbelievably vast amounts of legacy cruft, you will lose compatibility with a lot of older software, somewhat defeating the point of keeping X11 around. If you try to work around it, you will surely wind up spending an awful lot of time trying to not break things that haven't been updated since George Bush was in office. (In some cases, Senior.)
Maybe I can't make the case to everyone for why X11 is such a bad investment. I know a lot of people have a negative knee-jerk reaction to the idea that all legacy code must be thrown away and rewritten in Rust and other trendy things, and even something as old and weird as the X.org codebase just isn't enough to convince them that this is not one of those cases. Even in that case, I don't think the case for Wayland is really as weak as it seems based on its flaws. To be fair, I think most people complaining about Wayland are fundamentally right, but often frame things in a fundamentally poor way. Very few of the limitations of Wayland compositors that exist today are inherent, and many of them are getting resolved on a month-to-month basis. When developers claim "this can never be done because I don't have something like SetWindowPos", that's just annoying. Any feature can be done without direct access to these sorts of facilities, and I think that Wayland pushing window management tasks back to the window manager is something that will age very well even if it is painful at first.
I will definitely acknowledge is that for application developers, its annoying that you can do one thing on Windows, macOS, X11, BeOS, basically every other desktop system on Earth, and then you have to special-case that thing on Wayland. That's definitely going to be painful for developers who want to write software that runs directly atop Wayland. However: Open source software does not have the benefit of being able to move fast and jump on emerging trends as they start to become popular. I think that the developers of Wayland saw all the way back in 2008 that the longer term future was going to be different when it comes to window management. Obviously, they saw that desktop compositing would eventually be everything. But I think they also saw that for both privacy and security reasons and for the benefit of better window management, giving direct access to position windows is an artifact of many features that really ought to be provided by the window manager. If they wanted Linux to have a desktop system that felt "modern" in 2030, they needed to start making the moves towards that in 2008, because it wouldn't only take an enormous amount of time to make Wayland happen, but for the ecosystem to adjust to it as well. I think they also reasoned, correctly, that the vast majority of developers would not be using Wayland directly, but would be using GTK, Qt, SDL, etc. which I think is still true.
Also true is that some software and definitely some UI toolkits will never fully be able to cope with the windowing model that Wayland presents them, but this isn't actually the dealbreaker everyone seems to think it is.
First of all, I believe XWayland is here to stay for a long time. We're really not all that close to even being able to remove XWayland and I don't anyone really wants to soon. If developers are unable or unwilling to work to make their apps work on Wayland, that is fine. X11 is still here. Some developers will bravely start huge efforts and it will wind up benefiting the whole ecosystem by possibly introducing new protocols, providing tons of experience reports, and probably making compositors more robust all at the same time. A good example is Godot. Other software is just waiting for now and forcing XWayland; an example of that is Krita. A lot of eager enthusiasts may be bugging developers to start getting things going, but I think by and large there's no real reason to rush. For most users, XWayland is good enough.
Secondly though, I think that even old toolkits that rely on concepts like the ability to directly introspect and modify window geometry can be made to roughly work. Obviously, Qt 5+ do generally work on Wayland, with some limitations. (Well enough that most apps don't really have to change anything.) The winewayland.drv in Wayland makes Wine generally work on Wayland, with some quirks (probably a lot less than you're imagining, especially as of late.) While you obviously can't do everything the same, it is possible to virtualize old APIs and use workarounds. I don't think all of the old apps are forever doomed to XWayland as it may seem today.
Will the Wayland desktop be "ready" in 5 years? I think it will be "ready" in closer to 1-2 years, at least if the current rate of progress keeps up. Rather than being worried about the Wayland desktop being ready from the compositor/protocol/application end, I'm more concerned about the continuing progress on the NVIDIA end, which has been promising from multiple angles but still a bit slow moving.
> Modern users have high DPI displays, variable refresh rates, multiple monitors, and panels with HDR color space support. X11 was just never going to work well for this. KDE Plasma 6.3, on the other hand, handles any of these situations quite well and I've been using it on a daily basis.
Everything from your list except HDR worked in X11 years before it started to work in Wayland compositors. Maybe not perfect, but better than any Wayland compositor could do the same until only a year or two ago.
The amount of time it took to get at least feature parity with X11 in Wayland stack is ridiculous. I'm not really sure it wouldn't be better if all that time went into X11.
> Everything from your list except HDR worked in X11 years before it started to work in Wayland compositors. Maybe not perfect, but better than any Wayland compositor could do the same until only a year or two ago.
- X11 has no DPI virtualization or way for windows to communicate their DPI awareness. DPI is all handled by toolkits and desktops. Poorly. With multiple monitors, scaling is often buggy or entirely incorrect, only really working for one of the monitors. (How much you notice this obviously depends on what your desktop is like. Inside GNOME and KDE with "native" GNOME and KDE apps only, it should work decently most of the time. If you're i3wm or anything though you're pretty much guaranteed to have a bad time.)
- X11 indeed does have support for variable refresh, but it doesn't really work very well. In my experience it has basically always been buggy and weird and caused things to misbehave and go choppy for no reason. Before they introduced AsyncFlipSecondaries in 2021, the behavior with multiple displays was essentially unusable. No matter what you do, you pretty much just have to live with tearing on VRR+multi monitor. Much better off disabled.
- And yep, X11 just doesn't have any form of HDR/color management.
> Maybe not perfect, but better than any Wayland compositor could do the same until only a year or two ago.
As far as DPI scaling and VRR goes, this is false. I adopted SwayWM 7 years ago (from i3wm) specifically because I wanted my laptop to actually work with DPI scaling when I docked it. I actually don't know when VRR started to work right in SwayWM because I didn't yet have a VRR display, I just know that it already worked right when I tried it.
Note that for much of that time Wayland didn't have proper fractional scale support, yet I had my laptop at 1.5x scale during most of this time. You'd be hard pressed to notice, because apps could still just render at 2x scale and then it would get virtualized and downsampled. That might sound bad, but that's also exactly what you get with macOS's display scaling, and people usually consider macOS display scaling to be pretty good. (To be more particular, macOS renders apps at either 1x or 2x, but then scales the entire framebuffer to get fractional scales. Clever... I guess.)
As far as color management goes... well, X11 definitely couldn't do it better than any Wayland compositor, since it can't do it at all.
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...
> 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 have a feeling gnome has struggled more with wayland than kde. For a while i could not drag and drop across screens or to applications i switched to with alt+tab. I dont know if those are fixed. One that isn't fixed that I had happen just yesterday: menus locking focus to one app. If I open the file transfer popup in nautilus I have to first close by clicking somewhere else in nautilus, or else I can't click anywhere. I don't think I ever had that issue under x.
The only bugs I have seen in KDE are in sddm, but I managed to find a theme where they don't exhibit.
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.
> 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.
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.
> 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.
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.
> 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?
I don't miss the X11 days where I had to patch restoring window positions out of every application that did so. Good riddance.
Just that last time I had the application on a side monitor doesn't mean it should move itself after launching. Its especially bad if you often reconfigure monitor layout (for example laptop sometimes using external monitors).
> Reopen window, and reposition it where the user last placed it
Under Wayland, this is not the responsibility of the application, but the responsibility of the display server. You tag the window using the new toplevel tag protocol, and the display server will remember things like user position, size, always-on-top settings, and similar.
> Normally that requires windows knowing where they are in absolute coordinate space on the display. From what it sounds like, that's not possible in wayland?
It is neither possible to know where a window is nor to place it. That is purely up to the server, and under Wayland the goal is to tell the display server what it needs to know to create the UX the user would want - with a recurring focus on respecting user preference over having applications enforce the developer's preference.
But, it's important to note why it's made the display server's reponsibility: because the alternative was already broken under X11. Take a multi-window app that wants to open an old-fashioned "tool" menu. The application wants to place it to the left of the main window, which seems simple - until you realize it's not.
If the window opens fullscreen, the window would end up off-screen or on a different screen - okay, so we check if we're fullscreen and overlap the window instead. If the window opens near a screen edge or on a small screen, it might be too close to the edge - okay, so we also check if the left side of the main window is near a screen edge. Simple enough so far.
But then you run a tiling window manager (i3, awesomewm) and all new normal windows become tiles that pop up after predetermined rules, and random floating windows will be an error. Or you run PaperWM or Niri where the screen has an infinite horizontal size and so checking if a window is near an edge is always incorrect as the edge moves as needed. Or you run a VR window manager (we have those now!) so windows have not just X and Y, but also Z, pan, tilt and roll that the application does not know how to manage. Or you have a display server running on one of the OLED monitors that fold in and out like a recent CES lenovo laptop. Or...
Applications trying to micromanage their windows are effectively re-implementing a window manager that is always going to be making very heavy and wrong assumptions about the current window management paradigm and end-user preference. Instead of porting already broken duct-tape from X11, Wayland works on protocols that describe the intent properly - for example, by describing that an auxillary window is associated with the parent and should default to a placement to the left of it, rather than manually moving it.
(My personal opinion, unrelated to any project, is that traditional multi-window is a very fragile legacy design paradigm that doesn't make any sense, and that keeping operations to a main window and only using windows for isolated tasks - e.g., different workspace, file selectors, etc. - gives much better and more stable UX. Splash screens also no longer belong in a world of multi-tasking - just open the main window immediately, and if the app needs additional time to prepare, show the "splash" in the main window and transition later. That way, the user can multi-task and place the window instead of being interrupted by an application thinking they should cover up the center of the screen and randomly glitch windows in an out of existence.)
> My personal opinion, unrelated to any project, is that traditional multi-window is a very fragile legacy design paradigm that doesn't make any sense
That's all well and fine, no one is forcing you to build or use software this way. But there are domains where this is the predominant UX design and it's proven to be robust for decades.
Reading between the lines a bit and from browsing some mailing list posts/gh issues, it seems like Wayland developers have a deeply held arrogance towards application developers that are surprised to find out the applications they have been developing for years are "wrong." The truth is that GUI software on Linux is already a minefield (which is why most people don't bother to support it) and making it less-like-Windows is not going to make it easier for people to port their desktop applications. I get the desire for targeting things-not-like-Windows (tiling WMs, VR, tablet/mobiles, etc)... but those aren't desktop applications.
It seems crazy to me that there's so much feedback from desktop application developers that is being ignored or dismissed.
> That's all well and fine, no one is forcing you to build or use software this way. But there are domains where this is the predominant UX design and it's proven to be robust for decades.
Nothing about it is robust, it just exists. It has been around for decades, sure, but it also has not been common or popular for at least a decade or two now. It primarily exists in old applications still rocking their original, unchanged UI.
I have sympathy for existing applications, but I strongly believe it would be entirely inappropriate for a new application to be written with such UI - it was never a good idea, nor did it ever work well. It was just an idea that we have moved on from.
> It seems crazy to me that there's so much feedback
Not specific ot Wayland, but there is always absurd amounts of "feedback" to any high profile projects, which unfortunately means that most of it is useless noise, hit-and-run tantrums over the mildest inconvenience, and "ideas for solutions" by people who spent less than 5 minutes trying to understand the problem. This in turn means that it can sometimes be harder than it should be for good feedback to make it through.
> 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.
> 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.
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.
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.
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.
The permissions setup seems to work fine on macOS though. I can grant an application permission to view and manage other windows. Doesn't flatpak have user configurable app permissions as well?
I don't see how all-or-nothing is better than letting the admin whitelist what they need and blacklist that they don't
Working with existing applications as is requires a ditect mapping, and any restrictions or asynchronous prompts would break any existing assumptions in platform agnostic code, so it wouldn't solve things completely.
If you make something possible to do something with a permission or configuration, app developers just tell users to accept or configure to not ask, and then we're worse off than if there was no permission at all: the security is bypassed and only the inconvenience remains.
It takes a surprising amount of thought and work to do this in any meaningful way, and it cannot be done in a way that isn't somewhat disruptive.
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.
I couldn't find an explanation for the need for cursor warping support, someone in Lobsters said it might be so the "cursor could move with a moving object" which doesn't immediately resonate with me, as a frequent CAD, even LiCAD, user. Hmm.
Chances are "cursor warping" here refers to how "cursor locking" is typically done in win32 (every time the cursor moves, record the distance and reset it to the original location). Ironically, in the announcement about cursor warping being released, they say that it's not reliable for that use case, but that a "cursor lock" was already implemented. So it would be funny if KiCAD was just too stuck in Windows mentality to realize that what they needed was already supported.
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).
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.
"We do not investigate or support bug reports related to Wayland-specific issues"
Well put, guys! This is the way. It wasn't broken, nobody needed to "fix it". Now they "fixed it" & it IS broken, it is not your job to pick up the pieces! I tip my hat to you for having the balls to just plainly state so.
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.
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.
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)
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
CAD software, in general, tends to have a bit of a historical baggage problem. The oldest software is _old_, so it has all kinds of UI quirks because there was basically no standard of how to design UIs. And it's an area where people build up a lot of muscle memory and get upset when it changes, so any given tool tends to basically keep the same decisions almost indefinitely (and users/devs will have all kinds of rationalisations about how it's actually better, not just what they've gotten used to). And then the newer CAD tools start by copying an old one (KiCAD is very obviously based on EAGLE) and then change a few things around, but not too much, so you still get something far away from a typical UI. There's basically nothing that starts from scratch, and for a lot of patterns there's no obvious 'standard' to implement, either (I feel this pain when swapping between 3D applications: how do I pan, rotate, or zoom? It always takes a while for me to figure it out again, because I don't think any two of the 10 or so applications I use do it exactly the same way, and realistically most of approaches are fine, it's just the variety that's the headache)
Cursor warping makes sense in Blender. You can drag something past the side of the screen and it wraps back to the other side and you can still keep dragging in the same direction. In other contexts it would make sense for the cursor to lock at the edge of a widget and for the widget to scroll. Only when dragging.
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.
> 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
Wayland was designed by people who didn't quite grok the X way and decided to forge a different path. That's fine, but people also shouldn't expect Wayland to be a drop-in replacement for X in all cases. Thus a mature X-based project like KiCad is doing the right thing by focusing their efforts. If you need KiCad? You need X. If not? Run free with Wayland.
That is a odd statement since the people that designed Wayland are, by and large, the same people that maintained Xorg.
In fact the Wayland devs are the primary group of people maintaining what is left of X11.
The reality is that a lot of X11 design is simply a bad idea. Which is what one would naturally expect given its pioneering nature. By the mid 1990s it was already obsolete and didn't match up with how hardware worked nor how people were using computers.
What has allowed it to persist to this day in Linux is more along the lines of:
* we just that we had a really good open source implementation with a very dedicated developer base and some commercial support from companies like Redhat.
* compatibility with X Servers other then XFree86/Xorg was no longer relevant since the rest of the world has long abandoned X11. So aside from a few nitch cases were people wanted X11 apps on their Windows desktops using properietary X Servers it no longer really mattered.
* X11 allowed extensions (most of which didn't work with network transparency, btw)
* Widget authors, mostly QT and GTK, went through great efforts to avoid using X11 and working around limitations.
KiCAD is just a unfortunate case. They use a kinda odd toolkit, wxWidgets, and happen to depend on a lot of X11 specific behavior for some of their application's features.
So it is less of a situation of Wayland devs not understanding X (they probably are some of the few people that actually understand it deeply).
Wayland actually has really good X11 comptatibility through XWayland and for most applications it doesn't cause issues. But for KiCAD it does. And they are just being honest about it.
Accomidations are being made for KiCAD type behavior and probably KiCAD will update and change things to meet them somewhere in the middle and in not too long it'll become a forgotten issue.
> That is a odd statement since the people that designed Wayland are, by and large, the same people that maintained Xorg.
I keep reading this -- sometimes, verbatim. I don't know if you are just posting the same stuff everywhere you can, or it's in the database of some LLM bot, but it wasn't true the first time I saw it a week ago, and subsequently incorporated my response into my article here:
The same mostly Red Hatters who maintain X.org on Linux are the same people designing Wayland, but there is a lot more to X11 than X.org.
As I replied to someone -- you? -- last time:
«
There's a crucial but often overlooked distinction here. Yes, X.org develops the reference implementation of X11, but it's not the only implementation, and it never was. X.org was forked from XFree86 around 2004, and although development is dormant, XFree86 still exists.
There are or have been multiple active forks of X.org. OpenBSD uses Xenocara, developed independently. The FreeBSD X11 server and NetBSD X11 servers are their own forks, too. Although it's very different, the X11 server for Apple macOS, XQuartz, is also still around – even if it's not bundled any more.
The proprietary UNIX variants that are still in maintenance also have their own ports. Solaris 10 offered a choice of three but Solaris 11 has only its own version of Xorg. AIX has AIXwindows with its own X server. HP-UX offers two [PDF], one for HP Visualize graphics cards and another based on XFree86 for other GPUs. Before XFree86 was mature, there were a number of proprietary commercial X11 servers for Linux, such as Metro-X and Xi Accelerated-X.
Windows has its own GUI, of course, but it's been possible to run UNIX binaries on Windows NT ever since the first version, Windows NT 3.1 in 1993 – and since X11 runs over the network, the machine running an X11 app (the "client") can be a different computer to the one displaying the app (the "server"). As such there are multiple X11 servers for Windows, both for local and remote apps. Some are proprietary commercial servers, such as OpenText Exceed, X-Win32, Netsarang Xmanager, MobaXterm, and X410, among others. There are also multiple FOSS X servers for Windows, including VCXsrv, Xming [note, HTTP site], and Cygwin/X.
Many of these use code from X.org, but that's the whole point of FOSS. They aren't written by or maintained by X.org, and even if it and all Red Hat staff stop work on X11 completely, that doesn't mean these downstream projects will suddenly cease to exist.
»
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.
> 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.
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!
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.
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...