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.
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.
It is not enough to make a better product.
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).
But why would the distros do that? It takes effort and has real costs for them.
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?
xwayland cannot ever be removed, because wayland, by design, will not have enough functionality to replace it. So one can either support X desktop environments with their own individual bugs, or one X implementation that has the needed features and works consistently for all DEs
If developers drop off there’s not much we can do. It’ll eventually have to be removed or become a bigger security risk than developers say it is already.
Support on the x server itself has dropped off precipitously since Wayland hit the mainstream and most small x11 DEs are trying to build off of WM like wayfire or wlroots.
So, even though KDE Plasma has significantly advanced Wayland, a stronger push is still needed to drive the change further.
I don’t think kde plasma was the only one. Anyway, it just feels natural for xwayland to stop pushing for feature parody and for focus to switch over to Wayland after a while.
The biggest target for developers is the Ubuntu/Debian platform so their switch to Wayland should motivate other projects and paid applications to at least take notice.
New projects will try to support both but typically will focus more on Wayland. There’s already an unintentional incentive to partially support xdg protocols Wayland relies on thanks to flatpak.
Until I cannot run software on X11, I won’t switch over knowingly.
Please explain
Why would someone stay with x even though it’s deprecated, architecturally broken and unmaintainable
Because Wayland is STILL lacking a lot of things that people need.
Could you give me some examples so I can understand what’s missing and being waited on?
for one, it’s missing a good chunk of A11y stuff, activity watch requires something to monitor the active window, there is a PR for that, still not merged, this has been an issue for years
It’s missing protocols that will let applications request to be a privileged application, which is necessary for applications to use other functionality.
Missing protocols to control always-on-top / layers, which is needed for OSKs to function, and a couple other A11y things off the top of my head.
It’s not just a11y either, Window positioning still isn’t merged, which means if your app opens two “windows”, you cannot currently select where to open them, or to even bind two windows together (Android emulator does this for instance).
There is a LOT wayland is missing, it IS getting better, just at a snails pace.
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.
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.
