Adam Jackson On The State Of The X.Org Server In 2020

[remenic]

Instead to waste their time they should commit themselves to the switch to Wayland.

The end-users or the developers? Because end-users shouldn't have to "commit" to such a thing. It shouldn't be an undertaking for the end-user but a drop-in, seamless replacement. It's not. I could switch, if I switched to a different WM and avoid using apps that are broken in Wayland. Not only might that affect my productivity (which my employer will not like) it might mean learning a new workflow. I'm not going to commit to that, unless Wayland brings something so good it makes it worth it.

Not saying I'll never switch, but I won't switch today. Probably not tomorrow, either.

[jntesteves]

Or better help KDE, because it seems someone messed up their priorities. It came sooner than they thought.

Won't happen because KDE is "abandonware"

[paulpach]

"So, is Xorg abandoned? To the extent that that means using it to actually control the display, and not just keep X apps running, I'd say yes."

Speak for yourself, AJax. Wayland still sucks, especially if you're using KDE and/or Nvidia driver. Trying to run Wayland would be "choosing to make my life worse". I'll try again in 5 years. Maybe KDE will get its stuff together and maybe Wayland devs will stop being passive-aggressive dicks toward the Nvidia (and other) binary drivers.

I suppose it depends on what "abandoned" means.

Is there active development going on in Xorg as a means to control the display? No, that has clearly stopped, the maintainer himself is telling you so. The developers have abandoned it.
Are people still using it? Yeah, most distributions are currently using it by default. Users such as yourself have clearly not abandoned it.

Obviously, that is not sustainable long term. Either people will gradually switch to Wayland as the technology matures or someone will step up and "add more thrust to the pig" as Ajax puts it.

[JPFSanders]

Similarly to the issue with the NVIDIA blob, (where most normies don't understand/know what is wrong with it from a Linux kernel perspective) most people doesn't understand what is the problem with Wayland.

I will try to clarify it using language and books as a metaphor:

English = Language
1984 = A well known book written using the English language.

Then X:

X11 = Display Protocol (Language)
X.org (xfree86) = Display server implementing the X11 protocol. (Book)

Then Wayland:

Wayland = Display Protocol
Cagebreak = Compositor implementing wayland protocol
Cardboard = Compositor implementing wayland protocol
dwl = Compositor implementing wayland protocol
river = Compositor implementing wayland protocol
Sway = Compositor implementing wayland protocol
Velox = Compositor implementing wayland protocol
waymonad = Compositor implementing wayland protocol
Enlightenment = Compositor implementing wayland protocol
Greenfield = Compositor implementing wayland protocol
Grefsen = Compositor implementing wayland protocol
hikari = Compositor implementing wayland protocol
KDE KWin = Compositor implementing wayland protocol
Liri Shell = Compositor implementing wayland protocol
labwc = Compositor implementing wayland protocol
Mutter (Gnome) = Compositor implementing wayland protocol
wayfire = Compositor implementing wayland protocol
Weston = Compositor implementing wayland protocol
wio = Compositor implementing wayland protocol
Cage = Compositor implementing wayland protocol
Maze Compositor = Compositor implementing wayland protocol
Motorcar = Compositor implementing wayland protocol

Some of those support display managers, some of those don't.

Wayland depends on a buffer technology called GBM, all compositors support it.

NVIDIA has other plans and came with its own buffer technology called EGLStreams

All compositors support GBM.

Only: KDE KWin, Mutter (gnome) and Weston support Nvidia's EGLStreams"

When some functionality is missing in "Wayland" 90% of the time is something missing in Gnome or KDE or whatever compositor you happen to be using Wayland as a protocol is feature complete and doesn't impose any functionality constrains as it aims to be a general purpose display protocol as opposed to how X was conceived (IE: built-in fonts, or printer server)

That means that for example screenshot applications or remote access are to some degree, compositor specific.

This implies that if you want to stream using a Gnome streaming application you will have to be using the Gnome project's window manager. Or the KDE streaming application will require the KDE window manager.

Wayland is a good design, and the community may well go with it because X11 is old and atrocious (it works though) and Wayland is a viable alternative.

But call a spade a spade, it was IMHO a bad idea not to agree on common desktop things like remote access or permission management from the beginning, although as mentioned above it was done to keep the display free of non-display things.

Sooner or later the practical outcome is that there is going to be a screenshot protocol and everything that implements Wayland is going to have to implement that protocol as well.

The required negotiation for that to happen is taking/going to take years and delay Wayland adoption. If they'd designed that at the same time as an optional part of the Wayland protocol it would have saved time and confusion.

Add NVIDIA's disdain for desktop Linux and you have the current situation.

[Volta]

Wayland needs 20 years to be normally usable.

You need 100 years to stop being a moron.

[JackLilhammers]

Nobody from Linux gives a shit about nvidia and their binary blob. Keep dreaming or hire at nvidia and bring them Wayland support. It's proprietary crap after all, so it's an only way to fix it. AMD, Intel already decided how they want to support Wayland and nvidia has nothing to say here. What a fucking aggressive stance from nvidia fanboys.

Or better help KDE, because it seems someone messed up their priorities. It came sooner than they thought.

Of course, because nobody on Linux wants to use CUDA.
Nobody would ever think of using Nvidia cards to accelerate Blender, TensorFlow, or PyTorch, because it's just proprietary crap after all.

[tildearrow]

Oh no Michael, why did you do this.... The thread is split now and we couldn't make it to 300 comments :<

[nanonyme]

Apart Adam Jackson, Who else is been working on the Xserver? It's his personal opinion, or is he the only man in the world hacking the Xserver now?

My understanding is main issue is there have been release blocker regressions in X server core for like years. It's not practical to release all of it anymore because honestly there are close to zero people who care about X server (like ajax said xfree86) who are developers. Hence why it keeps getting bug fix releases every now and then from branch. It is a very clear mark of an unhealthy project that trunk is unreleasable for years. It is not just someone's personal opinion.

[Volta]

Of course, because nobody on Linux wants to use CUDA.
Nobody would ever think of using Nvidia cards to accelerate Blender, TensorFlow, or PyTorch, because it's just proprietary crap after all.

I was talking about kernel developers. If nvidia doesn't work, blame nvidia. It's such simple. Kernel devs won't fix proprietary crap and proprietary crap has to obey the law.

[M1kkko]

Alright, it's 2020 now, so I guess it's time to give this Wayland thing a shot again.

Does anyone know: Does wayland still have proper hardware cursor support? You know, computer mouse cursor? Drawn independently from the desktop? On top of the framebuffer? By hardware?

Last time I checked (a little over a year ago) the mouse movement was still noticeably sluggish compared to X. There's no way I'm making the switch before they support computer mice properly.