Wayland seems ready to me but the main problem that many programs are not configured / compiled to support it. Why is that? I know it’s not easy as “Wayland support? Yes” (but in many cases adding a flag is enough but maybe it’s not a perfect support). What am I missing? Even Blender says if it fails to use Wayland it will use X11.
When Wayland is detected, it is the preferred system, otherwise X11 will be used
Also XWayland has many limitations as X11 does.
for better and worse, XWayland works perhaps too well
Not on Cosmic Epoch Alpha 1 but yeah 😆
I heard wayland is hard to develop for and xwayland work a little too well, idk I’m not a programmer
I think X11 works out of the box but Wayland needs more knowledge and effort for now.
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.
Some many specific issues with Wayland… Maybe that’s a reason. X11 is a huggeee dependency for a long time.
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.
Oh hey, I love your work on Plasma’s HDR and color management. Glad to see you on Lemmy.
Wayland does not work with screen readers like Odilia or Orca. Because Wayland leaves blind users behind, it’s a total non-starter.
True…
Out of the loop, why is that ?
Not an expert, not an insider. Just commenting to inform about what i know.
When wayland was designed, security was a concern and it was handled differently than in X decades ago. The is good.
Under X any application can be a screenreader and see your data. This was okay when you trusted everything on your machine, but is a problem today.
Under wayland’s original design, no application could be a screenreader. That’s bad. It took way too long to agree on how to make exceptions to the rule, e.g. for screen readers, screen sharing in video calls, etc.
Thanks, I understand.
Also out of the loop, but my guess is that Wayland hasn’t defined a specific API for the purpose yet, and their security model doesn’t allow programs to see the content of other programs’ windows. X11 doesn’t attempt to keep programs from seeing what other programs put on screen, so no specific API is needed there.
Thanks !
Wayland “leaves blind users behind” due to its security oriented design. A protocol or portal of some kind is going to need to be created to solve this problem, but progress here is severely lacking.
That’s pretty shocking tbh
Also XWayland has many limitations as X11 does.
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.
Yeah I agree. Maybe some day X11 will be seen as something legacy that needs to be deprecated. But not now…
X11 has exactly one developer who’s a vaccine denying turbocunt German, everyone else has dropped it and it’s codebase is practically unknown territory with security risks.
Look man, it’s dead already
xwayland covers most use cases already anyway
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.
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.
Wayland will perform better than X as there is no server it has to go through. It can talk almost directly to hardware
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.
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.
Thanks for the inside.
Yeah Blender seems like an exception.
Also that means I play lots of Wine/Proton games and many web apps / Electron don’t care.
Wine and Proton have actually put a ton of work into Wayland support, it’s very far along. I wouldn’t be surprised for Proton to have a native Wayland version soon.
Great to hear that!
Because it doesn’t matter for most apps. XWayland works fine.
Even Blender says if it fails to use Wayland it will use X11.
What are you trying to say? Of course it does. Pretty much every Linux app still supports X11, because a lot of people are still using X11. Only exception I’m aware of is Waydroid.
I believe Wayland should be the default, but we should have the option to switch to X11 (using XWayland on Wayland) if desired.
Wayland is the default on blender, that is what that text says
Average over-enthusiastic Wayland promoter:
I am not sure I understand, OP is clearly misinterpreting the text they quote
Yes And I’m just pulling his leg for being overly excited
Wayland for better or for worse is still in development, it’s actively changing and a lot of developers can’t (or don’t wanna bother) keeping up…
As a disclaimer: I really like Wayland and use it as my daily driver for months now with KDE/Proton.
Now my answer, based on my best knowledge:
Because there is no real Wayland to implement, the base Wayland protocols are extremely bare bone and most of the heavy lifting is done by all the different wayland compositors like hyprland, proton, Mutter, weston, wlroots, gamescope so as a developer you don’t have one target to program against (X11) but lots of different wayland implementations and those are not always doing things the same way or providing the identical interfaces/API or have the same level of features.
On my system is at least one wayland only program that works absolutely fine when started in a wlroots environment but crashes (reproduceable on different systems) with a segmentation fault in Mutter or Proton.
It is still young and underdeveloped.
It is advertised to be simpler, but I don’t understand any of this words thrown in this thread. And I don’t care. Pulseaudio and pipewire is still making me troubles, even thou alsa worked without issues for me.
Point it, make it clear and stable and we will come. Until than we will use the beast we know. It os mich easier when there are no options, but Wayland is fighting something that exists and it takes time and effort.
Another problem is they pushed it to early and people got burned. Until I start seeing “I switched to Wayland in one command and everything works” I (as a user) will not touch it (unles my distro decides to drop X).
In my opinion, that’s because X11 lacks proper abstract for many things like screenshot, screencast, color managerment and etc, so the applications have to use many X11 implementation details to implement these features. It leads to high-coupling code with X11 so move their code to wayland and ensuring it works correctly and is consistent with the old behavior is difficult.
As someone who tries to look under the hood for a lot of the open source software I run, one thing that I have noticed is that there are a lot of cases where the general sentiment seems to be
port to what. Wayland still doesn’t support a number of things that some applications require. A lot of developers that I have interacted with would rather have the app run through XWayland rather than have a wayland version of the app with less features or certain features grayed out.In the case of one project in paticular, that being the Sunshine game streaming project. I have personally witnessed. Them implementing a solution for wlroots based compositor. Having that solution eventually break as wlroots based projects deprecate the protocol they were using in favor of a new one and now that protocol is looking like it too is old news and is going to be deprecated in favor of a newer and better protocol. What I am getting at here is that protocols not existing isn’t the only problem, but things are still very much in development. Even applications that implemented wayland support are being put in positions where they need yet another rewrite because things are far from finalized and still moving pretty fast.
So summarizing Wayland is not ready yet for everyone and current Wayland support can easily be broken with newer releases?
In the case of one project in paticular, that being the Sunshine game streaming project
That’s a terrible example, because they completely ignore the many many years old standardized APIs (screen casting and remote desktop portals) that they could use, in favor of doing hacky and broken things that require root access instead.
Even then, is that a documentation and centralized standards issue? Was there some list they could have/should have looked to that said ‘this is how that is implemented on Wayland vs X’?
The github repo has tons of issues about the problems caused by the hacks (from the cursor not being recorded, to it not working in Flatpak, not working with virtual displays, to even preventing graphical sessions from starting!) with the suggested solution of just using the remote desktop portal… I don’t know what the problem is, but it’s not a lack of knowledge.
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?
Come on with that load of hot trash 😭
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 ;-)
If I understand correctly, Wayland does provide better desktop security. At least two of the common issues are tied directly back to that.
Screen sharing apps, which need to access what one or more other apps are showing, and screen readers for the deaf, which need to access what text other apps are displaying.
Wayland intentionally recuses itself of these problems. That’s understandable, as these problems aren’t specifically in the realm of a display protocol. However, this has led to some significant problems.
Specifically, since there is a power and implementation void, and the Wayland crew haven’t stepped in or endorsed any particular way to fill it, each compositor/desktop library is now implementing it’s own means to achieve these ends. This leads to other problems.
You want to write software for X for some of these things, and regardless of the DE you’re working in, there are more fundamental ways to address the information you need. But if you want to do so with Wayland, there’s no “fundamental” layer to reach for, because it’s handled by the DE compositor and toolkits.
So you need to do it the KDE way, or the Gnome way, or the wlroots way, etc etc - and what if you want it to work with all of them? Simple: just code it multiple times and deal with multiple different frameworks, each with their own learning curves, restrictions, and quirks.
…by which I mean, “/s, jk jk, not actually simple.”
Really, my hope at this point is that maybe kde/plasma and gnome will standardize around wlroots (i.e., there is no hope).
So, failing that - maybe a single library for accessibility that does the work once (multiple times, but once), and is adopted and used by kde/gnome/wlroots, and a single library that does the same for display sharing.
Oh it sounds like you understand it correctly :-)
Thank you for taking the time to type this all up, you have expertly summarized the situation and I’m very grateful. Even with focused research it can be very hard to gain an objective understanding of complex subjects these days… doubly so when polaring topics like how to do desktop linux right are involved.
I suppose it would be foolish of the Wayland devs to wade into the middle of those waters if they want their work to remain beneficial to all. And suddenly the abstract technical details in the linked article make more sense to me… they really want to remain abstract from some of the implementation details.
This does seem a bit grim… and it perfectly explains why my problems could be fixed and one distro/wm and not another while still somehow being a “waylaid issue.” I suppose the best solutions/implementations will probably at least end up being shared in principle… I don’t really know enough about the current state of either desktop to be sure, I just wanted to say something positive :-)
Honestly, it’s pretty normal for Linux. It’ll fracture until it becomes glaringly obvious that there’s a problem, and then it’ll get standardized, and the standard may be supported in the next version.
Ubuntu could have gone flatpak. They didn’t. Kde and gnome could have come to a common agreement about desktop-related stuff they have in common. They didn’t. So it goes. The real pain points eventually get fixed.
Non linear evolution at it’s finest ;-)
It’s a lot harder to keep track of than it used to be but (holy crap) we won… mostly.
Honestly? Yeah. I agree. At the very least, a solid niche has been carved out, and it’s growing. I like that.
I’d really like to see more governmental support, but… …so it goes.
May programs do though
Minority rather than majority.
