Blender’s Wayland support is not great because they’re doing stuff from scratch. They’re not using an existing toolkit like GTK, Qt, Electron, or even something like SDL to get Wayland support.
But if you’re using an existing toolkit things are much easier and support is automatically there, you just need to do testing to ensure everything works.
The common biggest things that still use Xwayland are Chromium based apps and programs running under wine/proton. Chromium has an experimental Wayland mode that works well enough, but definitely has some bugs, especially around windowing. Wine Wayland is in the works.
Some applications, such as those with tablet demands, are not met by current wayland des with proper tablet support and xwayland is currently the better option. This may have changed in the last year or so, but this is roughly my recollection of certain big art programs.
Xwayland doesn’t get input in some special way, it uses the exact same Wayland protocols to get input events as native Wayland apps. All claims about it being more complete or anything like that are nonsense.
Krita forces Xwayland because they have some X11 specific code they haven’t bothered porting away from, that’s all.
If an app has only ever supported X11, then it probably doesn’t care about those limitations (the apps that do care probably already have a Wayland version). And if an app doesn’t care about the extra stuff Wayland has to offer, then there’s not really a reason to add the extra support burden of Wayland. As long as they work fine in XWayland, I think a lot of apps won’t switch over until X11 support starts dropping from their toolkit, and they’ll just go straight to Wayland-only.
Plasma deprecated their X11 session in v6 pending removal in the future, and Redhat has already dropped it in Fedora & will do for EL in the next release.
Plasma didn’t deprecate X11. Though some developers hinted that the Xorg session will probably be dropped before Plasma 7 and before Qt drops X11. But nothing concrete.
Oh indeed not deprecated, my bad. Wayland is default and “preferred” (how they’re deciding what to prefer I can’t imagine), and X11 is confirmed to be removed in a future release.
Wayland isn’t even adopted by every desktop environment yet. xfce, cinnamon, mate, lxqt, and all the ancient window managers all use x11, and all have their users.
If it works on xwayland, chances are it won’t be switched for a long time.
Because it’s so complicated that given a page (page and a half) to answer the simple question, “Why does Wayland support still give you more problems than solutions?” We had to describe it like the summary of a PHD theses in client server architecture?
Do you want the short answer? The short answer is “Because there’s a lot of applications that do a lot of different things and getting a good design for a protocol that supports all of those things is a process that takes time”
With the headline, yeah… kinda :-) Your answer plus a bit of “this is why it’s important.” And I would have grunted and gone back under my bridge…
I’m feeling a bit sheepish about my comment on the other side of the day.
But I was also hoping for a lot more. Better desktop security… and that’s underselling it because my understanding is we’re pretty much coming from zero, so this was always going to be rough.
I have yet to run into an insurmountable issue, but I’ve just hopped distros rather than (successful) troubleshooting. Always makes me grumpy ;-)
So software like CAD is funny. Under the surface, 3d CAD like FreeCAD or Blender is taking vertices and placing them in a Cartesian space (X/Y/Z - planes). Then it is building objects in that space by calculating the mathematical relationships in serial. So each feature you add involves adding math problems to a tree. Each feature on the tree is linearly built and relies on the previously calculated math.
Editing any changes up tree is a massive issue called the topological naming problem. All CAD has this issue and all fixes are hacks and patches that are incomplete solutions, (it has to do with π and rounding floating point at every stage of the math).
Now, this is only the beginning. Assemblies are made of parts that each have their own Cartesian coordinate planes. Often, individual parts have features that are referencing other parts in a live relationship where a change in part A also changes part B.
Now imagine modeling a whole car, a game world, a movie set, or a skyscraper. The assemblies get quite large depending on what you’re working on. Just an entire 3d printer modeled in FreeCAD was more than my last computer could handle.
Most advanced CAD needs to get to the level of hardware integration where generalizations made for something like Wayland simply are not sufficient. Like your default CPU scheduler, (CFS on Linux) is setup to maximize throughput at all costs. For CAD, this is not optimal. The process niceness may be enough in most cases, but there may be times when true CPU set isolation is needed to prevent anything interrupting the math as it renders. How this is split and managed with a GPU may be important too.
I barely know enough to say this much. When I was pushing my last computer too far with FreeCAD, optimising the CPU scheduler stopped a crashing problem and extended my use slightly, but was not worth much. I really needed a better computer. However looking into the issue deeply was interesting. It revealed how CAD is a solid outlier workflow that is extremely demanding and very different from the rest of the computer where user experience is the focus.
It’s true what you write, but it’s not related to Wayland/X11.
But this is the reason CAD software can’t use multiple cpu cores for geometry calculations. The next calculation needs the result of the previous one, it can’t be parallelized.
Because Wayland is fundamentally very different from the older X protocol, and many programs don’t even directly do X. They leverage libraries that do it for them. Those libraries are a huge part of the lag. Once GTK and Qt and the like start having a stable Wayland interface, you’ll see a huge influx of support.
A big part of the slowness is why Wayland is a thing to begin with. X hid a lot of the display hardware from apps. Things like accessing 3d hardware had to be done with specialized display clients. This was because X is natively a remote display tool. You can use X to have your program show its display somewhere else. Wayland won’t do that because that’s not the point. Applications that care will have goals for change. Applications don’t care will support it once someone else does it for them.
Right now, the only things that would benefit from Wayland are games and apps that make heavy use of certain types of hardware. Half of those don’t care about linux, while the other half is OK with X and xwayland.
It is not enough to create all tooling and libraries to seamlessly migrate to the new product, but it helps.
There also needs to be a great big positive reason to make the change. Paying developers, huge user base, the only hardware support, great visuals, etc.
Until I cannot run software on X11, I won’t switch over knowingly.
Once the desktops switch to Wayland and all distros ship with Wayland by default, support should slow.
Ideally, developers stop improving xwayland over time and go into maintenance mode for a bit. Once it goes into maintenance mode, developers should naturally fall off as it winds down.
If every desktop makes a very public announcement about the xwayland protocol being put into maintenance mode, actively supported apps should switch over. It’s up to the public how long they want to keep maintaining xwayland (open source etc).
They’re already starting to go that way, in a couple years Linux mint is even going to support Wayland. Ubuntu and fedora has already defaulted to Wayland. Fedora is actually deprecating xorg in a few releases. Budgie wants to have full support next year.
There isn’t much more than the testing they already have to do every release. Infact not having to support legacy code will free up resources for the whole Linux community as well as cutting the time in half for validating packages on distros. Every package that runs on xorg also runs on wayland, they have to test both.
Granted some have custom tools they’ll be working on but it’s going to be a while before every major DE supports Wayland. I’m curious, you think the distros have to implement their own version of Wayland?
Considering that Ubuntu, Fedora and any distro with Gnome or KDE as the default DE already come with Wayland as the default, it is clear they have been testing their own shit when it comes to Wayland and then shifting to Wayland by default.
wayland.freedesktop.org
Oldest