XWayland 21.1 Release Candidate Offers Split From The X.Org Server

[muncrief]

...
Debian, Fedora (and next iteration of Ubuntu) are defaulting to Gnome Wayland. It is perfectly usable in general. What issues are you referring to?
...

I'm primarily referring to the issues with KDE and XFCE mppix , but also with all other things that aren't Gnome. If XWayland was a drop in replacement for X, which is how it was initially presented, it would just work with everything.

Personally I would only use XFCE as I prefer a simple, straightforward, desktop. I understand that many like Gnome and KDE but it seems to me that they, after the initial revulsion of the Linux community with the spinny convolution of Windows 8/10, began attempting to emulate it.

But to each his own, and that's the great thing about Linux. The core remains clean and stable, and users are free to make it look and interact pretty much any way they wish.

And by the way, I never actually commented on the main thrust of this article, which is combining a stable version of X with XWayland. That's actually a very good idea.

[AmericanLocomotive]

Pardon me if I'm misunderstanding things (as the Linux GUI/Graphics stack still baffles me for the most part): Is this article really saying that x.org - something used by nearly all distributions, has no one actively developing/working on it? How is that even possible?

[caligula]

Well, it doesn't appear that there's ever going to be a "drop in" Wayland replacement for X. Wayland was first released 9 years ago, and XWayland 7 years ago. And yet even the developers still have great difficulty with it.

I understand that the underlying issues are varied and complex, and know the Wayland/XWayland developers are working as hard as they can on remedying them, but X is so different and ingrained in desktops that I don't see a realistic alternative for at least another 5 years.

FWIW, Xorg has changed quite a bit during the last 9 years. For example, my X specific xf86 display and input drivers are less than 190 kB in size. The xorg packages are smaller than 10 MB. It's obvious that not only was development effort spent on Wayland, but they've also cut down unmaintained parts of X. There's hardly anything X specific left.

[muncrief]

Pardon me if I'm misunderstanding things (as the Linux GUI/Graphics stack still baffles me for the most part): Is this article really saying that x.org - something used by nearly all distributions, has no one actively developing/working on it? How is that even possible?

From what I understand Red Hat was the primary contributor to X, but abandoned it because they wanted to try and force quicker adoption of Wayland.

However Wayland is only fully functional on Gnome and as the many articles on Phoronix, and any quick internet search, reveal it's quite difficult to integrate it with anything else.

Hopefully others will step up to maintain and develop X, but it's incredibly complex and requires a knowledgeable team to take it over, so it's a classic story of putting the horse before the cart. Wayland is definitely the future, but it's such a huge change that it's going to be painful for quite awhile.

But Red Hat is primarily concerned with Red Hat and Gnome, which is certainly their right. So if users want to maintain other much simpler desktops like XFCE, which require a functional and stable X system, they're pretty much on their own now. However it looks like KDE will soon be fine, as they're big enough to dedicate the resources necessary to switch to Wayland.

[sabian2008]

It doesn't seem likely as the patches are not merged upstream yet, but perhaps they'll get patched in on a distro package level anyway when Nvidia's 470 cycle drivers (that ought to provide driver-side support for this) make it into the repos.

Thanks for this. There was a new commit there adding preliminary support for GPU offloading in Xwayland. That's the good enough solution for 99% of Nvidia users I think. Any iGPU from the last ten years can run two (or maybe three) displays at high resolution and you can lunch games, blender / whatever in the dGPU and display it using the iGPU. You can therefore avoid the pile of crap the EGLStreams backend is.

[CommunityMember]

From what I understand Red Hat was the primary contributor to X, but abandoned it because they wanted to try and force quicker adoption of Wayland.

That is a bit of an mis-characterization.

Over the decades, various organizations have contributed to the entire X stack. Red Hat among them, but they were not the only. But managing the entire QA and release functions was a very substantial effort, and Red Hat was the most recent (presumably mostly because their customers at the time used/needed X, and Red Hat often stepped up to support what their customers needed).

Long ago when the people responsible for X decided it needed replacement, they designed what we now know of as Wayland (it was designers and promoters of X that decided Wayland was the future, as X had run its course, and its limitations were becoming far to problematic). Red Hat was part of those discussions and proposals, so certainly concurred, and put substantial efforts into Wayland while continuing their X QA/release role at that time.

In recent times those efforts with promoting and enabling Wayland throughout the stack moved to the point Red Hat apparently no longer saw a reason to staff the QA and release process for the entire X stack as Wayland just worked (for their major paying customers, at least). And Red Hat chose to stop resourcing that entire X release process, even as the need for that limited piece of X known as XWayland will need to be supported for some time in the real world as there are still X apps. But that (XWayland) is now the target for release, not the entire X stack.

Hopefully others will step up to maintain and develop X

And this will almost certainly not happen (although individual patches to integrate on an ad-hoc basis and the occasional security patch will almost certainly still be floating around). Others have had the chance to step forward to manage the entire X release process for quite some time. People have explicitly asked for others to step forward(*). No one with the resources needed to do so has volunteered.

One should never say never (again), but at this time it certainly looks like there will never be a 1.21 release.


(*) If your org is large enough to resource that entire process on an ongoing basis, and somehow missed all the discussions, go talk to the X project, as there could be room for you.

[oiaohm]

I'm not sure what a XWayland-based XServer is other than a Wayland compositor?
You could of course force every application to use XWayland and get window privacy by running an independent XWayland session for each application. You'd still need the copy-and-paste tools, screen-sharing, etc. introduced by Wayland compositors. Also it would be quite inefficient compared to just run the GUI framework, e.g. GTK4, natively on Wayland...

Xwayland is not a Wayland compositor. Kind of comes clear when you look at the rough overview. Bare metal X11 roughly looks like one of the following the following.

1) X11 server backend->X11 server frontend
2) X11 server backend->X11 third party compositor->X11 server frontend

The server X11 backend has the internal X11 compositor and X11 driver interfaces and so on. Yes this is also the area of the X11 server that does screen capture and input injection.

Xwayland looks like.
Wayland compositor->Xwayland

Xwayland here is the X11 server frontend parts

This explains why injecting input and screen capture are not working with Xwayland as those are going to the X11 Server backend that is not there so the functions nop. Yes X11 server frontend code in Xwayland is directly hooked up to Wayland client application interfaces.

Now if Xwayland was in fact a Wayland compositor it could be using libdrm to get direct screen access or directly injecting input at least for X11 applications..... Not being a Wayland compositor does put a lot of limitations on what Xwayland can do.

[mppix]

Pardon me if I'm misunderstanding things (as the Linux GUI/Graphics stack still baffles me for the most part): Is this article really saying that x.org - something used by nearly all distributions, has no one actively developing/working on it? How is that even possible?

The X window system was developed in the 80s and 90s. However similar to VNC, its governing bodies are defunct and the protocol cannot be changed anymore. Any change would result in a non-conformant implementation.

It dates back to a time where computer/display architecture barely evolved beyond the terminal. For example, it includes clipboards, a print server, drawing primitives, or networking/network transparency. However, today's desktops are primarily based on extensions to enable a modern look'n'feel etc.

Xorg is an X server implementation. For the reasons mentioned, it is more or less a Frankenstein that comes with 40 years of baggage that cannot be removed. It is one of the most complex opensource projects (possibly competing with the Kernel) and the least rewarding.
Hence, the main Linux DEs + industry came up with Wayland and Apple with Metal. The goal with Wayland was to break the X server functionality down to make it maintainable and move barely related parts to separate packages.

Xorg (as in the server) is more or less a walking dead. However, the X protocol is still very useful as a compatibility layer for Linux/Wayland and Apple/Metal.

[mppix]

Xwayland is not a Wayland compositor. Kind of comes clear when you look at the rough overview. Bare metal X11 roughly looks like one of the following the following.

1) X11 server backend->X11 server frontend
2) X11 server backend->X11 third party compositor->X11 server frontend

The server X11 backend has the internal X11 compositor and X11 driver interfaces and so on. Yes this is also the area of the X11 server that does screen capture and input injection.

Xwayland looks like.
Wayland compositor->Xwayland

Xwayland here is the X11 server frontend parts

This explains why injecting input and screen capture are not working with Xwayland as those are going to the X11 Server backend that is not there so the functions nop. Yes X11 server frontend code in Xwayland is directly hooked up to Wayland client application interfaces.

Now if Xwayland was in fact a Wayland compositor it could be using libdrm to get direct screen access or directly injecting input at least for X11 applications..... Not being a Wayland compositor does put a lot of limitations on what Xwayland can do.

Exactly the point that I was trying to make.
Xwayland runs on top of Wayland. Therefore, a Xwayland based Xserver is a Wayland compositor.....

[oiaohm]

Exactly the point that I was trying to make.
Xwayland runs on top of Wayland. Therefore, a Xwayland based Xserver is a Wayland compositor.....

Xwayland is a Wayland client application. So its not Compositor. Thing to remember as gamescope from valve shows and the Weston reference compositor shows. Is that a Wayland compositor can in fact be a X11 application as well. So if Xwayland was a full blown wayland compositor it would be possible for it to run directly on top of X11 bare metal as well but Xwayland is not its only a Wayland client application.

Being a compositor is different to being a client application. Compositor has to have all your hardware interface library bits and those open up some really wacky running locations.