It's Time To Admit It: The X.Org Server Is Abandonware

[jo-erlend]

Canonical's usage of CLA.

People did not want to support the Mir protocol, so eventually it died out and Mir is just another Wayland compositor.

Mir specifically didn't have a protocol because they didn't want people to come to depend on one. Personally, if I create a large software system and you tell me you have a small fix for it, but that you will only give it to me if I give up all my rights, I will not take your fix. Do you really think that makes me unreasonable?

[mdedetrich]

Making Xwayland work does not require changing X11. GLX Relay and zink are a Mesa3d code base patch and both can result in XWayland coming functional on Nvidia

The hard reality here is Valve supporting legacy applications in there store don't need a new version of x.org X11 server at all. Updates to mesa3d yes.

Valve has absolutely no reason to do development work on x.org X11 server.

mdedetrich the reality here is you have been clueless the reason why Nvidia Xwayland does not work is that Nvidia drivers don't install the parts so Xwayland can work. Of course since this is driver failing to install required parts this does not require patching X11 server to fix. Instead its patching the drivers. The drivers for XWayland are not in the X11 x.org code base but are in fact in the mesa3d code base.

WTF are you going on about?

The NVidia blob doesn't even use MESA, it provides its own Vulkan and OpenGL API's which sit in the blob's driver. If you are using a desktop with an NVidia card (along with the blob) then you won't even have MESA installed (although this depends on the distro, some of them install MESA even though you don't need it and it will be unused). If you are on a laptop with hybrid graphics then MESA is only going to be used for the integrated GPU inside the AMD/Intel CPU (the whole point of optimus is for demanding 3D applications such as games to use the discrete card, in this case NVidia with its blob).

This is why in the README.md of the project you are referrencing (gamescope) says that it requires acceleration to work with XWayland for NVidia because there isn't any MESA. This means that the NVidia blob will have to work properly with Wayland (both so that gamescope actually works and also so that people will use NVidia + Wayland in the first place).

[kpedersen]

That's ridiculous! I need to write one universal comment that covers everyone's viewpoints.)

Your comment was... actually very good and perfectly balanced.

Whilst I am in the "Pro X11" camp for now, I didn't find myself disagreeing with any of your points.

Your summary that both are in a bit of a mess certainly seems true but where does that leave us? What would you suggest? Also what are your predictions for the future of "drawing to a sodding screen" on free platforms?

[Danielsan]

This is another non-sense by IBM/Red Hat: the industry movie niche relies 99% on Linux (99% RHEL/Cantos) all the proprietaries software in use and proprietary drivers work only with X. Blender has just an experimental support for Wayland without considering that you get CUDA and OPENCL only with proprietary drivers (NVidia/AMD) and those do not support wayland. Is RED HAT dicthing this market? Or, are there secret agreements with other companies, like M$, to move this niche under WSL2/DirectX?

You can't trust corporations at the end of the day they are watching only their wallets.

[oiaohm]

The NVidia blob doesn't even use MESA, it provides its own Vulkan and OpenGL API's which sit in the blob's driver.

Really you have not looked how the driver hooks in with XWayland have you its Nvidia designed libglvnd0. So anything that filled the required areas of libglvnd0 for XWayland will make Xwayland accelerated work.

https://gitlab.freedesktop.org/mesa/..._requests/6429

Its about time you do some reading.

If you are using a desktop with an NVidia card (along with the blob) then you won't even have MESA installed (although this depends on the distro, some of them install MESA even though you don't need it). If you are on a laptop with hybrid graphics then MESA is only going to be used for the integrated GPU inside the AMD/Intel CPU (the whole point of optimus is for demanding 3D applications such as games to use the discrete card, in this case NVidia with its blob).

Its really not that straight forwards. If Nvidia does not provide XWayland solution. Redhat will provide a XWayland solution based of Mesa code base abstracting over the Nvidia binary blobs so they run without needing root X11 server that is the GLX Delay path.

This is why in the README.md of the project you are referrencing (gamescope) says that it requires acceleration to work with XWayland for NVidia because there isn't any MESA.

To be correct in release mesa there is no XWayland for Nvidia. In development branches of Mesa we have GLX Delay as a option. The zink option also offers to fill in the libglvnd0 stuff in XWayland. Remember most applications built with pure Vulkan work native Wayland and already work with Nvidia with all wayland compositor solutions supporting eglstreams and that includes gamescope that gets it from wlroot..

This means that the NVidia blob will have to work properly with Wayland (both so that gamescope actually works and also so that people will use NVidia + Wayland in the first place).

Nvidia blob it self does not have to work directly with Xwayland as long as abstraction makes it work somewhat. Its not like valves older titles need the best performance at first.

Its really simple to miss that driver with XWayland is 100 percent abstracted by libglvnd0 that Nvidia designed and Nvidia has failed to release the add on library so libglvnd0 for Xwayland works. So now its up to redhat with GLX Delay or Zink to fill in the gap Nvidia has created with their incompetent driver development.

Basically the pure reason why Xwayland does not work with Nvidia is 100 percent Nvidia fault. Heck Xwayland was design to use the abstraction Nvidia designed. What Nvidia is libdlvnd0 defective and you have mandated everyone else use it and will not use it yourself????

[mdedetrich]

Really you have not looked how the driver hooks in with XWayland have you its Nvidia designed libglvnd0. So anything that filled the required areas of libglvnd0 for XWayland will make Xwayland accelerated work.

https://gitlab.freedesktop.org/mesa/..._requests/6429

Its about time you do some reading.



Its really not that straight forwards. If Nvidia does not provide XWayland solution. Redhat will provide a XWayland solution based of Mesa code base abstracting over the Nvidia binary blobs so they run without needing root X11 server that is the GLX Delay path.

Okay so I just read the merge request and yeah this is going around circles.

In order for this to work, EGLStreams needs to work properly (as mentioned in the merge request). EGLStreams working properly with compositors is the reason why NVidia blob is currently not working with Wayland, quoting directly from the merge request

GLX drawables are backed by EGL objects, specifically by an EGLStream whose EGLConfig is compatible with the GLXFBConfig associated with the drawable. We use EGL_KHR_stream_producer_eglsurface on the client side and EGL_KHR_stream_consumer_gltexture on the server side. glXSwapBuffers thus corresponds to a simple eglSwapBuffers on the EGLStream, which is then handed off to the X server to complete. Xwayland consumes this stream as a texture and blits it into the EGLStream associated with the Wayland surface for the window.

Note that this means a GLXWindow corresponds to two EGLStreams: one from the X client to Xwayland, and one from Xwayland to the Wayland server. Any excessive blitting generated by this indirection is your EGL vendor's bug, because this is the API we have to work with.

Because of this the solution seems to have quite a few things that are not working, i.e.

1. VSync
2. Resizing windows (this can break some game launchers which is a similar issue wine-wayland, i.e. https://github.com/varmd/wine-wayland)
3. A lot more which I am probably missing

In fact from what I can see, its only doing the bare necessary required to run GLXGears which is yeah, not much...

So yeah, by the time this will work properly with games we would already have NVidia's blob running with Wayland via EGLStreams anyways. This whole discussion is emblematic of the whole problem, of course there are "solutions" but they are also giant hacks which have severe usability problems. When talking about games, they really stress GL as much as possible in terms of features they use (i.e. using SwabBuffers for VSync) and until ALL of these things are working correctly like they do currently on X the status quo will remain the same.

[dnebdal]

I'd just like to thank pal666 for reminding me why writing many short consecutive posts in a thread is a bannable offense in another forum I sometimes visit - not because it's explicitly in the rules, but because it's caught by their catch-all "don't be too annoying" rule.

[oiaohm]

Okay so I just read the merge request and yeah this is going around circles.

In order for this to work, EGLStreams needs to work properly (as mentioned in the merge request). EGLStreams working properly with compositors is the reason why NVidia blob is currently not working with Wayland, quoting directly from the merge request

https://gitlab.freedesktop.org/mesa/..._requests/6429

Read again. Its not EGLStreams working properly that is the problem. Gnome and KDE in the Wayland compositors already support EGLStreams for Nvidia this days. We are talking about a year ago that KDE and Gnome in Wayland only mode with no X11 application support support EGLStreams.. Its the XWayland bit that is not working.

This is all because when Nvidia designed EGLStreams they did not design it to be compatible with GLX by libglvnd that XWayland needs or for X11 inside X11 acceleration to work right.

Because of this the solution seems to have quite a few things that are not working, i.e.

1. VSync
2. Resizing windows (this can break some game launchers which is a similar issue wine-wayland, i.e. https://github.com/varmd/wine-wayland)
3. A lot more which I am probably missing

In fact from what I can see, its only doing the bare necessary required to run GLXGears which is yeah, not much...

So yeah, by the time this will work properly with games we would already have NVidia's blob running with Wayland via EGLStreams anyways. This whole discussion is emblematic of the whole problem, of course there are "solutions" but they are also giant hacks which have severe usability problems. When talking about games, they really stress GL as much as possible in terms of features they use (i.e. using SwabBuffers for VSync) and until ALL of these things are working correctly like they do currently on X the status quo will remain the same.

Really the huge hacks are what we are going to have because Nvidia have not implemented their driver right. Nvidia provided libglvnd as the abstraction for X11. Then when Nvidia made EGLStreams they have not made there X11 implementation use it so have not updated there libglvnd X11 interface.

So result is Nvidia is now maintaining two stacks instead of one. EGLStreams and the X11 stack.

Remember Valve is still selling to people games from the 1990s.

Like it or not the problem with Xwayland and Nvidia cannot be fixed in x.org X11 code base. The problem is 100 percent purely made by Nvidia own actions. Nvidia designed EGLStream and libglvnd glx in incompatible way. Yes Nvidia designed both parts. Yes Nvidia maintains the repositories for both parts. Without Nvidia deciding to fix it the result is going to be one mega huge hack no matter who other than Nvidia does it.

So valve taking over the maintainership of x11 at x.org is not going to help this problem as the problem is not in the x,org X11 code bases. In fact valve would be better of to put time into making like wine wayland work instead.

[mdedetrich]

https://gitlab.freedesktop.org/mesa/..._requests/6429

Read again. Its not EGLStreams working properly that is the problem. Gnome and KDE in the Wayland compositors already support EGLStreams for Nvidia this days. We are talking about a year ago that KDE and Gnome in Wayland only mode with no X11 application support support EGLStreams.. Its the XWayland bit that is not working.

Yeah I know that Gnome and KDE have "support" for EGLStreams but there are still quite a few problems. To make things worse you have DM's that wont even launch if you have the blob installed (even if you are not using it for compositing, looking at Sway here) which makes the situation even more fun for end users

This is all because when Nvidia designed EGLStreams they did not design it to be compatible with GLX by libglvnd that XWayland needs or for X11 inside X11 acceleration to work right.

Which is the correct way to do it given the context and the fact that NVidia is stuck with the blob. If someone is going to deprecate X11, it makes complete perfect sense to make a separate interface.

Also FYI, the EGLStreams interface is very similar to what is used on Android and Windows, this is why they suggested it. Its actually LInux that is doing things "their own way" without knowing how compositors/desktops are done in other OS's (and there is a very strong argument that other OS's are doing a much better job here).

Really the huge hacks are what we are going to have because Nvidia have not implemented their driver right. Nvidia provided libglvnd as the abstraction for X11. Then when Nvidia made EGLStreams they have not made there X11 implementation use it so have not updated there libglvnd X11 interface.

Perfectly reasonable for NVidia to do this since X11 is meant to be deprecated. The real problem here is that NVidia suggested a solution that works with their driver (EGLStreams) and the entire community originally said "f off" because the suggestion came from an NVidia email.

Then when Linux people finally realized that apart from NVidia really doesn't have a choice (barring re-implementing their entire driver which isn't going to happen), EGLStreams is the best they can do. Note that NVidia blob can't work with GBM without a severe performance hit because they are fundamentally designed in a different way (grossly oversimplified, GBM is a synchronous interface where as EGLStreams is an asynchronous/stream based interface).

Also as another tidbit, NVidia actually wanted to use EGLstreams as the basic interface for compositing (since its an open standard approved by Khronos) but Linux people largely ignored this.

Like it or not the problem with Xwayland and Nvidia cannot be fixed in x.org X11 code base. The problem is 100 percent purely made by Nvidia own actions. Nvidia designed EGLStream and libglvnd glx in incompatible way. Yes Nvidia designed both parts. Yes Nvidia maintains the repositories for both parts. Without Nvidia deciding to fix it the result is going to be one mega huge hack no matter who other than Nvidia does it.

So valve taking over the maintainership of x11 at x.org is not going to help this problem as the problem is not in the x,org X11 code bases. In fact valve would be better of to put time into making like wine wayland work instead.

I am sorry but this is both NVidia's and Linux's fault. Linux stuck their head in the sand with the "we are superior" mentality and designed their graphics stack contrary to every how every other OS works and they didn't give any room for NVidia's blob. Every other OS apart from Linux makes the minimum amount of assumptions for how the graphics works and NVidia's blob is primarily a cross platfrom driver (this is the only way they can guarantee equal performance across different OS's).

And yes, EGLStreams isn't functioning completely correctly but again lets put things into context. Wayland was created TWELVE years ago and it took a good 6 years of constant bugs and fixes from various parts on the stack (MESA/GBM/etc) to get to where we are now. On the other hand, NVidia suggested EGLStreams even before Wayland, Linux said f off and so understandably NVidia shrugged their shoulders and didn't do anything since Linux didn't want to work with them. Fast forward more than a decade and suddenly desktop OS's are scrambling to get NVidia blob working with Wayland since devs want to move away from X11 and they didn't want to work with NVidia in the past. So in summary, Linux's OS graphics stack had 6-12 years (depending on how to measure it) to get things sought of working where as NVidia had a few years (at best?).

The biggest issue here Is Linux's developers unable to accept the fact that NVidia's stance is not going to change (for completely rational reasons) and to be collaborative in working with them. That is purely Linux's fault.

[MrCooper]

I can already predict the plethora of short live forks that'll eventually spawn out of X.org. To be clear, I hope that it's maintained to some degree, but it is time for something newer and better to come along.

What's lacking is people who actually do the needed development/maintenance work. Such people can work directly with the main xserver tree, no need for forks.