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.
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).
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.
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?
Nope. They do have to test their own shit.
Why make a change when one can just not?
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.
This is a thread about slow uptake by programs of Wayland.
X works for me.
Well it was you who implied that a distro shipping the DE with wayland has to do extra testing that they don’t do. I just replied stating that distros are testing and validating for wayland to be the default.
Good. No one is stopping you from using it.
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.
I do not care about security risks. If something made its way onto my system, I’ve already lost. I just want one implementation of something that gets the job done. And by “gets the job done” I mean it allows us to do things better, not disallow us from even having the option to do things because someone had their tinfoil hat on too tight. Ffs you can’t even set your window icon. I don’t care if kde has implemented that feature. If I use that, I’d be supporting kde, not wayland. It won’t work on other des and so the maintenance burden increases drastically.
Your arguments kinda weak, no offense. I do have a solution for you though. If you want to stick with a version of Linux that’s guaranteed to support xorg for eight years, I’d recommend Rocky linux! When that reaches EOL I guess you could just stay on it.
Enterprise plans on being fully switched over to Wayland by the next major version. You won’t be able to install xorg on redhat for example. The biggest contributors to xorg(Enterprise) are going to shift focus to xwayland to support legacy software on wayland.
Besides it’s exciting finally catching up to truly hardware accelerated desktops like Mac OS 10.0 and windows vista. At its heart xorg is a purely single threaded software accelerated bitmap based windowing system from 84. They’ve had to rewrite small but incredibly complex chunks of the code just to try to keep up with the modern world. Just look at the history of 3D acceleration in x11.
Your free to give it a good go though! The very same team that actively maintained xorg threw in the towel ten years ago when they diverted resources towards a new windowing protocol and they’re not going back.
new features are fine. But first and foremost, is not breaking existing apps, or committing to porting them yourself. So if desktop apps need to do xyz, then wayland needs to support doing xyz. period. No ‘but that’s insecure’, no ‘but why would you want to do that’ (for setting a window icon or positioning the window ffs). Support existing applications. I’m not saying it should support x protocols. But it should offer replacement features for existing apps to be ported to. And it needs to be wayland. Because it’s already the case that certain functionality is implemented for gnome, or kde, with incompatible apis, to fill in the void left by wayland itself. If I want an app to work as I want it, consistently, everywhere? X, with all its warts, is my only choice.
As an example, the accessibility protocols. They’re good to have. Except they’re opt-in. So incompatible with existing apps. Some apps need to restrict access. They could declare that and make use of additional functionality. But no, choose a default that break everything instead.
The argument that apps just need to be ported also assumes the app is still maintained. Are you willing to do the work yourself if not? Probably not. You’re just the one looking down on people like me for wanting functionality in existing apps to be “not literally impossible to implement”