Xorg development effort slowing in favour of Wayland
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Looks like unfortunately you compare Manjaro's Plasma6 with Slackware-current's stock Plasma5 .
Trust me that also in Slackware-current the Wayland/Plasma6 is faster than the X11 counterpart and it looks better.
I did mention that I thought the difference was explained by the version differences. I have a LOT of compiling to do to get the Kernel up to 6.9 and Plasma up to latest 6 release, and I did not want to have to wait for that to comments.
I am currently running current Slack, with Plasma 5 on Wayland right form the install and it works well. At these levels there is just no outstanding reason to choose it over X.Org. I think when we all have Kernel 6.9 and Plasma 6 there WILL be excellent reason for moving to Wayland. I see no reason NOT to run it they way I am right now, but many of of love Slackware BECAUSE you do not need to jump to unsupported versions to make Slack do what you want. It is dependable as it is.
That said, I really want to find time to do that compiling.....
The wayland leaders are mostly X.org leaders. That's it. We're running out of excuses not to use it.
Not mostly, entirely. It is the Desktop Team that develops and supports X.org, XWayland, and Wayland.
They are, buy the way, GREAT guys!
And I have NOT asked them, but my understanding of XWayland is a kind of server shim to translate X.Org calls by client software into calls (or SETS of calls) for Wayland. This allows X software that has NOT been converted to Wayland to run properly, although there may be a slight performance penalty.
I have tested it several ways, and it works for me. BUT I might not have tested what YOU do so take that for what it is worth...
I've been running wayland for years without issue in my workflow including gaming via proton etc. People like to conflate this X vs Wayland fight like its the Systemd one and to me its completely different. Which is best evidenced by the fact that the teams are the same! People need to stop treating this situation like its a fight which really.. isnt one.
I've been running wayland for years without issue in my workflow including gaming via proton etc. People like to conflate this X vs Wayland fight like its the Systemd one and to me its completely different. Which is best evidenced by the fact that the teams are the same! People need to stop treating this situation like its a fight which really.. isnt one.
Well, Wayland hasn't taken over all the Desktop projects and Windows managers, and login managers, dbus, polkit etc and marged them into a bundle and making all GNU/Linux GUI application depend on them just because.
And I have NOT asked them, but my understanding of XWayland is a kind of server shim to translate X.Org calls by client software into calls (or SETS of calls) for Wayland. This allows X software that has NOT been converted to Wayland to run properly, although there may be a slight performance penalty.
I have tested it several ways, and it works for me. BUT I might not have tested what YOU do so take that for what it is worth...
And that will doom Wayland. What's going to happen is that third party software developers will continue to target X, and only verify that their software compiles against the XWayland shim. This gives them the best of both worlds: compatibility with x.org and Wayland.
The only possible reason why someone would want to target Wayland would be to use Wayland-specific features. I don't know what they are, but I would think that most third party developers wouldn't care.
The only factor that can play in Wayland's favor is the widget stack. Gtk is fully on the Wayland bandwagon, so that speaks for all the Gtk-based ecosphere. But it's my understanding that Qt doesn't care and will continue to have X as the main target.
The only possible reason why someone would want to target Wayland would be to use Wayland-specific features.
I can think of another good reason. When I open an application, I usually want it to run full-screen (Xterms are an exception). I don't want a desktop that has some apps on it plus a sub-window overcrowded with other apps that won't run on the main window. That's messy and offputting. Users are going to look for applications that will run in the main window.
I can think of another good reason. When I open an application, I usually want it to run full-screen (Xterms are an exception). I don't want a desktop that has some apps on it plus a sub-window overcrowded with other apps that won't run on the main window. That's messy and offputting. Users are going to look for applications that will run in the main window.
I am running Wayland right now, with Plasma 6. Some of my applications are written for X and some have been written for native Wayland. I literally cannot tell the difference. Running some benchmarks under X.Org and Wayland with XWayland I might able to detect the slight performance difference, but it is not enough to notice without measurement.
XWayland does not open a window, it allows your X app to operate in the main display exactly as if X was running instead of Wayland.
I cannot imagine caring if applications are coded for one or the other, as long as they run properly in both. I CAN imagine not really noticing if the distributions I use totally drop X.Org at some point because everything still just works!
Funny how quickly the BSDs have been forgotten in all this. But that's the kind of arrogance and bullying we've come to expect from the various projects hijacked and monopolised by Linux.
Last edited by Gerard Lally; 05-16-2024 at 11:49 AM.
Funny how quickly the BSDs have been forgotten in all this. But that's the kind of arrogance and bullying we've come to expect from the various projects hijacked and monopolised by Linux.
Well, they're much smaller communities, but work is being done. There has been a large amount of work done to get XWayland and compositing window managers supporting the Wayland protocol, and many distros have held back until the significant wrinkles were ironed out. It does take OS-specific porting effort, so some the responsibility lies with the maintainers of those distributions. Gnome 3 and KDE Plasma 6 work AFAIU. Sway was ported years ago. OpenBSD gained kernel modesetting relatively recently, and that is required by Wayland desktop environment. FreeBSD can run some desktop environments with Wayland if desired.
Funny how quickly the BSDs have been forgotten in all this. But that's the kind of arrogance and bullying we've come to expect from the various projects hijacked and monopolised by Linux.
Many Linux users do not know that much of the GNU tool development has long taken place on BSD rather than Linux. I am not sure if that is still true, but all the rest of us have been dependent on GNU work from the BSD guys for most of the existence of Linux.
I still see some development of HURD (The GNU kernel) from time to time. It is not dead. Yet. ;-)
And that will doom Wayland. What's going to happen is that third party software developers will continue to target X, and only verify that their software compiles against the XWayland shim. This gives them the best of both worlds: compatibility with x.org and Wayland.
Maybe someone should write the converse of XWayland? WayX? Worg? Then 3rd party developers can write wayland clients to target Xorg running the wayland shim and we can run them without giving up our X window managers.
Maybe someone should write the converse of XWayland? WayX? Worg? Then 3rd party developers can write wayland clients to target Xorg running the wayland shim and we can run them without giving up our X window managers.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.