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

[Sonadow]

Choice is being taken away from Linux users, day by day.

Linux was never about choice.

It was always about letting people do whatever the fark they wanted to do with its source code by virtue of it being OSS.

[Ironmask]

choice is being taken away from Linux users, day by day.

I really hate it when people regurgitate the "Linux is about choice" crap, it's like an Apple fanboy saying Mac never gets viruses. "Choice" isn't some magical endless resource that flows out of Linux and is being restricted by evil people. Alternatives to software exist because real people are working on them, and it's a lot of effort to do that, even more so as software is just expected to do more than ever before, and probably will continue to do so. Software doesn't exist in a bubble, it needs the support of it's surrounding ecosystem. If a piece of software has no support from other software, like addons or API compatibility, then it's useless. And the more alternatives there are out there, the harder it is to write alternatives, because they all need to be compatible and work together.

Nobody's taking away your choice. Choice is restricted because it's a monumental task to create, maintain, and gain support for new software. Look at how much of an uphill battle Wayland has to go through, and that's with the entire industry supporting it. The only reason Linux had the illusion of "choice" in the past was because it was a toy OS with lots of toy programs. Now it's an actual serious OS with actual business software.

More importantly, alternatives aren't as important as customizing existing software. The more options and features existing software provides, the less reason you'd have to stop using it, and thus you won't have to go through the pain of replacing it and learning a new piece of software and dealing with the growing pains of it not working with other software you use. DEs are a perfect example of that, it's horrible to have to switch between them.

[oiaohm]

X11 is dead because it is a technological dead-end and this makes it a commercial dead-end. Once there was a Unix workstation market. Now, not so much. The linux desktop community on its own could never have sustained the development of X11. The Linux desktop market is not important enough; it never, ever was. We got lucky that someone else had a business case to build X11. Now, the business case & funding exists for Wayland (automotive for instance). Linux desktop is a hitchhiker looking for free rides, but the X11 ride is broken down on the side of the road. Wayland is motoring along.

This is not quite right. You have overlooked something important.

https://wiki.c2.com/?XwindowProtocolShouldBeStabbedAndBurnt

There is a repeating pattern of the Linux desktop community getting upset with X11 starting their own new non X11 solution and it dieing out due to lack of vendor support. This leads to a lot of work on mesa to make own open source drivers.

Like it or not there was a very long term goal to get away from X11 server. So its not that the linux desktop community could not have sustained the development of X11. Its how do you be highly motivated to keep X11 alive when you know it defective.

Please note the reason why X11 was not the default interface of MacOS is when they looked it the result was that X11 was brain dead stupid.

There has basically been a long arguement to kill X11 off. Nvidia is now basically the last hold out. So if Nvidia wants X11 server on bare metal to stay alive they need to pick up the x.org X11 server maintenance if not they need to update their driver to be compatible.

[timrichardson]

The big picture is that wayland has OEM support for embedded platforms, things that X can't run on. This is an important market. Wayland included this use-case in its design and therefore, Wayland is a product with a commercially viable future. Look at the enormous effort behind building a Wayland-native backend for Chromium. That was paid for by commercial interests that need it ... not for the linux desktop, but Wayland is a protocol: a linux desktop which supports Wayland can take advantage of this work.
No one is paying for X. It is commercially dead.

X11 is dead because it is a technological dead-end and this makes it a commercial dead-end. Once there was a Unix workstation market. Now, not so much. The linux desktop community on its own could never have sustained the development of X11. The Linux desktop market is not important enough; it never, ever was. We got lucky that someone else had a business case to build X11. Now, the business case & funding exists for Wayland (automotive for instance). Linux desktop is a hitchhiker looking for free rides, but the X11 ride is broken down on the side of the road. Wayland is motoring along.

[oiaohm]

I know the Wayland protocal is just that, a protocol so it doesn't really care about the underlying details. My point is about the current situation with Linux and the NVidia blob.

Those implementing compositors do care about underlying details so people don't have to implement duplication.

Yes because understandably NVidia doesn't want to spend time implementing a solution that Linux isn't going to adopt because Linux is hostile towards NVidia. To be clear, at the time the primary argument used against NVidia was a hostile version of "release an open source driver" or "use GBM directly" rather than finding a proper solution. For example KDE initially didn't want to implement EGLStreams not because of the merit's (and non merit's) of EGLStream's but because they didn't want to manage multiple codepaths and everything should be GBM based (which is kinda ridiculous because one of the main effects of Wayland being a protocol is that compositors have to deal with this).

To be correct you have not looked at libhybris right. Because that idea of GBM based is wrong. libhybris plugs into Mesa3d opengl/egl abstraction layer.

This is also two to tango. KDE stated there point they did not want to maintain 2 code paths. This does not mean everything has to be GBM at all.

Why are the Linux developers say to Nvidia support GBM. The reality is the EGLStreams cannot be implemented on top of Mesa either. EGLStreams not a universal abstraction layer it requires Nvidia particular logic.

On the other hand with Linux desktop wouldn't have accepted libhybris even if NVidia suggested it (in fact this is the first I heard of libhybris so I am reading up on it but since it is the first time I have heard of it thats already indicative enough.

This is without question wrong. Nvidia proposed libglvnd that is used to replace the Mesa universal abstraction layer that libhybrids depends on.

EGLStreams is an open standard and variants of it was used in the past (Android pre 2018).

That is no part used EGLStreams on Android devices this includes Nvidia. If you look the ARM Mali driver or any other non Nvidia android it does not use EGLStreams, Instead it uses hwcomposer set of Interfaces.

https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/

Please note in 2016 blog from KDE they are using by libhybris Android binary blob drivers. Nvidia binary blob drivers for Android at the time in fact worked with KDE because they exposed hwcomposer interface from Android.

You have missed how split brain Nvidia. EGLStreams comes out of the desktop/server departments. Yet the hwcomposer interface for Nvidia using Android devices come out of the embedded department. Please note the hwcomposter based driver for Android is also a GBM driver from Nvidia.

The fact is, the majority of NVidia's driver is actually a cross platform blob with an interface for every OS they support (old MAC'os with NVidia cards, BSD's, Linux and Windows). NVidia proposed a solution that gave the best performance for how their driver is designed (they said this directly).

Notice you did not write android and that is in fact correct. Nvidia Android support is out of a different department. And read what you said closer. Proposed a solution that gave the best performance based on how their driver was design this also means gave absolutely no consideration to how the other drivers of the platform were designed.

EGLStreams hits roadblock because its not design to provide hwcomposter interface Android needs and its not designed to be compatible with the existing pool of Mesa drivers.

This may be partially correct but at least according to https://github.com/NVIDIA/libglvnd, libglvnd does support EGL and also appears to be updated (last commit was 3months ago which from a company like NVidia isn't atypical workflow).

Sorry no this is Nvidia split brain. Its the normal workflow of the Nvidia embedded driver support team.

So I am not sure what the problem here is, at least according to that project repository NVidia does intend to fully support EGL unless I am missing something (the project is also open source so anyone can commit the changes necessary).

Yes libglnvd is design to take modifications so everyone driver stacks works. EGLStreams was taken straight to Khronos and set in stone with no plans to be modified to suit other vendors need. So you are AMD/Intel and other Linux GPU vendors and Nvidia walks up and say you will implement everything Nvidia way you really should not expect a good response. libglnvd is what comes out after Nvidia gets zero adoption of EGLStreams by other vendors heck when their own embedded driver development refuses to take it as well is EGLStreams absolutely screwed. For some reason Nvidia desktop developers keep on kicking EGLStream down the road.

Also FYI: Google is also developing a new kernel that will eventually replace Linux for Android and one of the main features of their new kernel is that it maintains an ABI for drivers which sit in userspace (in other words it works much better with proprietary drivers) rather than expecting everything to be in the kernel tree. This is because of very real issues that Android faces where a lot of phones are using outdated Linux versions and the Linux version can't be updated independently of proprietary drivers (which poses obviously problems).

This skips over a lot of important history. Android is first released with user space driver support on Linux. Vendors decide to use proprietary drivers in kernel space because it will be faster and more power effective so vendors over rode that orgonal idea. Is this the first time this has happened no.

Back in year 2000 there was a ABI designed for a universal to share the same kernel space binary blob driver between FreeBSD, Linux and other Unixs. Number of commercial drivers released supporting it the answer was 1 did the mainline Linux kernel support this the answer is yes. Nvidia also responds being locked out of internal kernel ABI stuff would hurt their performance so they would not be providing drivers. Yes this feature was removed from the Linux kernel for lack of usage and a open source driver had replaced the 1 commercial driver using the interface. So its a mistake to think Linux did not try to be more friendly to binary drivers.

https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst

Yes the issues that come out of that early experiment are written up here.

https://source.android.com/devices/architecture/kernel/generic-kernel-image

Google is not just looking at one solution to the driver issue. There is every chance that Google new kernel will have lack of driver support. Its all due to the performance effects of being able to optimised code paths with each other the mainline Linux kernel gives.

[pal666]

It doesn't matter that a word _can_ have several meanings. What matters, is the meaning it's supposed to have. In context of the Mir display server, it's obvious that the intended meaning is "peace".

obviously if they wanted to mean "peace" they would just call it "peace"

[lucrus]

Wake me up when I can run Sway without telling me that "--my-next-gpu-wont-be-nvidia".
Until then, Xorg works just fine with i3.

I'm afraid you can sleep forever then.

[karolherbst]

That's an good insight.

BeOS and Haiku run programs with full privilege. Windows XP and earlier did the same. Those operating systems were intended for single users. X11 is rarely used or allowed as a multi-user server anymore, so security would only protect users from themselves. That's what's stupid about Wayland. Wayland runs as a client application, but it tries to prevent stuff like keyboard grabbing, mouse warping, or giving any client program control of anything, even though everything is sandboxed to the user. That, too, only protects users from themselves. How about we treat people as competent and allow them to control their own hardware?

and what about running untrusted applications, like games? Or sometimes you also get malware and stuff. If the user wants to run a screen recorder or something under wayland the compositor can just allow it, but ultimately the compositor is in control and could ask the user before granting that. In X no such mechanism exists.

[sa666666]

sa666666 Did you quote 144hz in your now deleted post? It seems to me some of144hz's posts are gone, also all posts that quoted them. If that's the case, it wasn't your post that was problematic, it was just caught in the clean-up.

Well if that's the case, I sincerely apologize. And sorry for the outburst there, but it seems that coming to these forums and dealing with certain people is just getting more and more toxic. And on top of all that, all that's going on with Linux and the direction it's heading (for better or worse). And finally of course, COVID. This year really sucks, and I think nerves are frayed and tempers flare. It's certainly the case for me. That being said, there are certain people here that provoke this behaviour, and no doubt delight in it.

[mdedetrich]

Sorry bull crap on that Android bit. Android interface in fact has nothing todo with EGLStreams https://www.collabora.com/news-and-b...using-drm/kms/ In 2018 Android legacy interface was deprecated and replaced with Mainline Linux drm/kms/gbm this was not that hard since Android existing logic was already based off linux drm/kms/gbm logic to user space. https://github.com/libhybris/libhybris Yes you can dig though libhybris here that allowed android userspace drivers to be used with wayland and X11 solutions. Yes android old driver with libhybris in fact works with Xwayland without a problem.

I was talking about the framebuffer implementation which indeed has changed a couple of years ago as you pointed out, although slightly irrelevant considering most Android devices lag behind a couple or more years (and at the time NVidia used framebuffers which is the go to solution)

Android and Wayland are based of the EGL standard from Khronos before EGLstreams was added. Wayland starts in 2008 and EGLStreams from Nvida appears in 2009. Yes Android is even older they come out of 2003 EGL for their original libhybris user-space. EGLstreams is absolutely not based on the work Android it.

Wayland in its early years was a bit of a pipe dream and no one really took it seriously (no discredit to Wayland here, this is normal for something new).

Do note libhybris for android drivers was used in early Wayland development and it is from 2004 so wayland protocol was designed to suite android drivers of the time this is also why Xwayland with them works perfectly.

I know the Wayland protocal is just that, a protocol so it doesn't really care about the underlying details. My point is about the current situation with Linux and the NVidia blob.

Wayland protocol has hell of a lot in common with the way Android does things because old Android drivers were used in the early development process along side GDM drivers.

EGLStreams might have something in common with Windows but is absolutely not Android. If EGLStreams were in fact based around android user-space drivers interface plugging it into Wayland and XWayland would not be a problem.

EGLStreams and the Wayland protocol is not the same thing. I know that the Android protocol was very similar to Wayland, I was talking about the graphics driver stack.

That not the case exactly. Wayland protocol is 12 months old when Nvidia finally speaks up about EGLStreams and the first form is going to require major altering because you cannot run standard EGL applications on it. Took Nvidia another 3 years to get EGLStreams to be able to run normal EGL applications. So someone walks up to your door with something that is without question broken the answer really should be "f off" and that was early EGLStreams.

Yes because understandably NVidia doesn't want to spend time implementing a solution that Linux isn't going to adopt because Linux is hostile towards NVidia. To be clear, at the time the primary argument used against NVidia was a hostile version of "release an open source driver" or "use GBM directly" rather than finding a proper solution. For example KDE initially didn't want to implement EGLStreams not because of the merit's (and non merit's) of EGLStream's but because they didn't want to manage multiple codepaths and everything should be GBM based (which is kinda ridiculous because one of the main effects of Wayland being a protocol is that compositors have to deal with this).

And yes NVidia also didn't treat Wayland seriously because Mir also existed and also because of the whole "NIH" syndrome that the Linux ecosystem tends to get itself into. If I was NVidia I also wouldn't spend any time on this "brand new hot thing" unless I had some signal that it was going to be seriously adopted.

That is a no you have missed early Wayland using userspace Android users with the libhybris interface. So there was never any requirement for Nvidia to support GBM. EGLStreams is NIH by Nvidia like it or not. If they had followed libhybris model XWayland with Nvidia would work now. Libhybris uses the libglvnd Nvidia invented.

This is correct for Android, but not for Linux desktop. Android as far as the ecosystem goes is far more open to "proprietary drivers" and so I am not surprised that some solution was made because its in Google's best interest to do so (otherwise they can't release a phone).

On the other hand with Linux desktop wouldn't have accepted libhybris even if NVidia suggested it (in fact this is the first I heard of libhybris so I am reading up on it but since it is the first time I have heard of it thats already indicative enough.

But it was all Nvidia NIH work with no other supporters by any other vendors. If you are going to push something like this expect to be left holding the bag todo everything.

I am not sure what you mean by vendors. EGLStreams is an open standard and variants of it was used in the past (Android pre 2018). I mean you are implying that NVidia did a lot of effort to implement something completely different which apart from not being correct is also making no sense (why would NVidia spend all of their time making something completely new?).

The fact is, the majority of NVidia's driver is actually a cross platform blob with an interface for every OS they support (old MAC'os with NVidia cards, BSD's, Linux and Windows). NVidia proposed a solution that gave the best performance for how their driver is designed (they said this directly).

That is wrong and you repeat it. Wayland is before EGLStreams. Lot of people mix up EGL and EGLStreams. EGL is before wayland and before Wayland Nvidia has basically no useful EGL support.

Yes, technically Wayland came before EGLStreams but as stated previously no one took Wayland seriously because it was so new.

Basically nvidia is causing problems because they have not deprecated eglstreams and moved to libglvnd to provided normal EGL The way libglvnd does things does line up with Windows and Androids ways quite well. Eglstreams is Nvidia bastard child that need to be taken out back and put out of it misry. Yes what Nvidia does with Eglstreams could also be done by libglvnd using EGL. Remember libhybrids provided android drivers don't have GDM synchronous model either..

Remember Nvidia proposed libglvnd not providing a libglvnd wrapper to normal EGL for EGLStreams interface that is Nvidia failure.

This may be partially correct but at least according to https://github.com/NVIDIA/libglvnd, libglvnd does support EGL and also appears to be updated (last commit was 3months ago which from a company like NVidia isn't atypical workflow).

So I am not sure what the problem here is, at least according to that project repository NVidia does intend to fully support EGL unless I am missing something (the project is also open source so anyone can commit the changes necessary).

Also FYI: Google is also developing a new kernel that will eventually replace Linux for Android and one of the main features of their new kernel is that it maintains an ABI for drivers which sit in userspace (in other words it works much better with proprietary drivers) rather than expecting everything to be in the kernel tree. This is because of very real issues that Android faces where a lot of phones are using outdated Linux versions and the Linux version can't be updated independently of proprietary drivers (which poses obviously problems).