Could that mean an end to security issues that will never be fixed for X11? I wonder.
I don't think anyone struggles to realize that Xwayland is still going to be around. It has to be or RHEL 10 would fail to run less than half of the enterprise software it needs to stay in business.
These are all good things to think about. Effectively a libW11 (Xlib API but Wayland hooks underneath) will be useful to port software (and I am actually shocked that the Wayland ecosystem has *nothing* like this in place after almost two decades). However I fear this will simply allow for replacement of Xwayland over time rather than keeping Window Managers and the whole X11 flexibility alive. We need something to at the very least help port X11 Window Managers over. Perhaps a Wayland compositor that exposes an Xlib API as a way to add decorations?
My first reaction to that was, they'll probably do that limitedly for servers, which don't need graphical acceleration, but since they want to make it mainstream, they'll need graphics capabilities as you've implied.
Wayland can currently run on the X11 desktop like a Xephyr window, but on its own instead. Last year, I stumbled on a way to run a second X11 window manager (it wasn't Wayland) in a second virtual terminal on Ctrl-Alt-F10, I didn't write down the notes on how I did it, and I couldn't do it again.
In the text and arrow example, it was about forking Xorg instead to trim out legacy parts, and figure out how to make it modular, with what can be learned from Wayland. Then, making a compatibility layer for Wayland graphical toolkits to run on this version of Xorg. We may not need Wayland compositor layers, as we would be depending on X11 window managers or perhaps a new invention of X11 compositors.
www.jwz.org
Working great too. Even games perform super smooth in wayfire. I just played some Metal Gear Solid The Phantom Pain on Steam using Mizuma on FreeBSD 14.0 Release using Latest sources in /etc/pkg/FreeBSD.conf Excellent performance.there your areI've just switched over to using wayfire.
The problem is that Wayland *is* great for this. It is perfect for people who simply use their hobby machine to play Steam DRM platform games, browse the web, etc. It works really well and unfortunately this seems to be the culture of much of the Linux desktop community these days. They *don't* need all the benefits of Xorg, so they have no reason to complain or fix things. I do understand that.I've just switched over to using wayfire.
Indeed. Many Wayland users obviously don't need that to play their games though so are quite happy to see it broken for those who do. The rest seem quite happy with VNC-style Waypipe approach of sending across a full raster of pixels and then simply complaining about their internet connection speed. If you encrypt the stream, it is even slower.
One way to read this is that the blog entry is written by someone who actually dove into programmatic side of things and knows a thing or two.
Indeed. I mentioned that briefly at the bottom. However SSH does add overhead. You can instruct SSH to use a simpler encryption (or a NULL/dummy encryption) but the classic TCP approach from Xorg is still faster (once re-enabled of course). The SSH approach has an additional UNIX domain socket between the communication.
Although I haven't measured, but from my experience putting VNC through Wireguard VPN seems to be much better than through SSH.
Actually thats a good point. I don't quite know how they do it because it is using X11 technology behind the scenes. Because it is proprietary I tend to overlook it but this is exactly the sort of thing that *should* have worked its way into vanilla X11 communication by now. The successor to X11 should certainly be considering this technology (I understand the older version of nx-server was open-source).
I do agree. Xwayland is definitely a temporary stopgap to mislead people into believing that i.e Gnome/Wayland isn't as defective as it really is or to expose the true lack of native Wayland software. Once they have critical mass, they will very much enjoy turning it off.
It is not only the compositors. It is all the widget sets, the code already written and no real maintainer behind it. Who will port that? Noone. Outside of QT and GTK, what will work? Athena? Xaw? They need a way to keep the code running, and they need it to stop running. Not a good position.
