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

[blacknova]

Well, I think it is really possible to avoid excessive copying from full screen application by presenting the exact buffer application provided. That is what GBM and probably EGLStreams are all about.

And even resolution, refresh rate adjustment and page over presentation control can be coded in as extensions for Wayland.

The problem is - I'm not sure if there is standard for these extensions defined or every wayland compositor will try to do it on its own.

In the end If this will came to it - Valve can form some ready to use compositor, slap their own extensions on top and just provide Steam Linux users with "Big Picture" mode with separate login... joy.

After all if no standard compositor present why bother with compatibility? Are we even sure that couple of years ahead KDE and GNOME compositors will be compatible enough to run each others applications?

[oiaohm]

False. The compositor adds latency, like it or not. Always. There is no way this can be avoided, as we cannot predict exactly how long will the compositor take to draw the next frame.

That is absolutely not true for a Wayland Compositor. Exclusive Full Screen can be split in 2. Wayland compositor can do a zero copy buffer between the Application and GPU. That zero copy buffer in Wayland protocol design means the Wayland compositor does not have to draw the next frame at all if it has a full screen buffer from something. So you don't need Full Screen Exclusive mode as you need in X11 when you have zero copy buffer option. The zero copy buffer comes from EGL or Vulkan and was designed to be used with the wayland protocol.

With wayland the time for the compositor to draw next frame can be as low as zero due to the zero copy buffer effect. So in a well behaving wayland compositor an application covering the full screen should automatically have the Wayland compositor step out way. This is not like X11 compositor where you have to do Full Screen Exclusive and ask the compositor to step out way and allow a zero copy buffer. Zero copy buffer part of Exclusive Full Screen is basically built into the Wayland protocol and should be their if the compositor is implemented well.

The big thing you don't really want is the Exclusive Full Screen bonus of direct control over screen resolution this is not always a good thing.

Sure, wasted bandwidth and power. The dedicated circuitry on a separate monitor is often more power efficient, and guaranteed to deliver the scaled image in time.

Few errors here when you get into using TV as monitors you will find out that they are not always deliver the scale image on time if you are not using the common resolutions. Yes some monitors can skip frames on different resultions and is really really horrible,

Furthermore you did not consider this. What if the laptop cannot output... say... 4K at 60Hz but rather only 30? So what? Should I live with the lower framerate?!

There is no 100 percent perfect answer here. I used 4k as example but you can have that you also want to hide the fact you have 4K from application.

The problem is that if you use the graphics card for scaling the game you cannot be sure that the scaling time is constant. So there is a chance it could potentially miss a frame if the game is loading the graphics card too much.

This depends on the graphics card. Some GPU have decanted scaling circuits exactly like a monitor. Think LCD panel with no brains directly connecting to the GPU. So particular GPUs you can be 100 percent sure that GPU scaling is 100 percent constant.

The scaling hardware on a monitor is guaranteed to scale the image and never miss a frame.

This is a myth this is not in fact always true.

https://www.reddit.com/r/pcmasterrace/comments/6amgpl/psa_do_a_frame_skipping_test_on_your_monitor/

Some monitors you do a frame skip test on and they are skipping you can get them replaced under warranty others like TV where you are attempt to use a resolution that is not standard broadcast you have to live with the problem. So in a case you have a monitor with a hardware scaling issue on a particular resolution you will want to disappear that resultion.

OK, please look. 1080p does take less time to render than 4K, but what if I am still being bottlenecked? If we do the 1080p to 4K scaling on the graphics card, this means:

This is going to be fun. Stack of myths based presumes. Lot of these are depend on the GPU

- less performance

Depends on the GPU some GPU the buffer scale circuit is part of the CRT out path so always run so makes no performance difference at all. Of course if you are using shaders this is true.

- more memory usage (yeah, just to do the scaling)

Again this is depend on the GPU. The GPU with buffer scaling in the CRT path there is no more memory usage due to the fact the memory is always allocated..

- we do not know how long will it take (what if the card runs out of memory, has to destroy the scaled buffer (~32MB) and recreate it when the time to scale comes?)

One of the reasons why you will rendering at 1024p and upscale 4K is the fact you don't have enough GPU ram to render 4K complete scene in the first place.

Yes it true we don't know in the generic case for any random GPU how long GPU buffer scaling will cost. The somewhere between zero cost and lots of cost depending on the GPU.

You cannot expect application developers/game developers testing on limit hardware to be getting this right all the time.

Are you saying I should just buy a new monitor?
Why are you thinking backwards?! Where did compatibility go?

Being able to use your GPU to pretend you have VRR monitor when you don't means you can reduce your need to buy new monitor. As you are able to get the CPU and GPU reduction the application gets by using VRR methods without having a VRR monitor. Yes without abstracting the monitor away from the application the only way you can get this benefit is buy new monitor.

Poor performance, sure. Remember the Windows Aero days?
People playing games on full-screen often experience higher performance than windowed/composited (more so on low-end systems).

Yes I do and that is a X11 like compositor in Windows. That not a wayland compositor that has access to zero buffer actions. Wayland a window covering full screen if the compositor is done right should instant gain the performance of being executive full screen. There is more than 1 way to solve the problem.

Also something you miss is using the layer system in GPU so you can have part screen window that is change ie game and that buffer is going straight on to a output layer that is welded into single image in the CRT out part of the GPU. So lot of ways you want excursive output layer in the GPU as that basically gives you the same performance as Full Screen Exclusive while being a window. X11 compositors and Windows compositors are not designed to take advantage of output layers in GPU to their fullest.

Output layers is one of those fun things lot of people would not have a clue that when most GPU makes what it sends to monitor its always fusing 4 different buffers into 1 using a simple alpha masks. The first extra layer in GPU added was the mouse curses layer.

[oiaohm]

After all if no standard compositor present why bother with compatibility? Are we even sure that couple of years ahead KDE and GNOME compositors will be compatible enough to run each others applications?

The answer to this will most likely be yes KDE and Gnome compositors will be able to run each other applications. Because they do work with each other in this area they learnt a lot from the artsd vs esound problem.

But there is a bigger problem will non KDE/Gnome compositors be able to run KDE/Gnome applications this could be a bigger problem child. Both KDE and Gnome on Linux are going down the path of systemd user session management. Like really KDE and Gnome applications not working with Weston the reference Wayland compositor without major messing around is really possible.

[dragon321]

I use Firefox Dev on Wayland too, but now videos are flickering and often there is just a black screen. Menues of addons are mostly white boxes. The close button in CSD mode is broken. Scaling is not working. And the basic renderer flickers terribly on Plasma Wayland. Then Firefox just shows again only a Wayland icon. Just look at the bug reports before asking people what they are talking about ;-)

You can find bug reports for basically everything but it doesn't mean it is problem for anybody.

It was a few months back. Parts of the UI didn’t work right, and websites didn’t draw completely. I’ll give it a shot and see if it’s improved.

I don't remember for sure when I switched for Wayland but as I said it's perfectly reliable for me now.

[Ironmask]

This discuss is getting looong.

IMO Xorg will be commercially abandoned, but will continue as a community project.
just because it has no commercial support does not mean it is abandonware, openssl has been running with just pure donation after all, not even commercially supported prior heartbleed.

I mean, this sounds like many previous discussion in the past to me.
like GNOME2(now MATE), Systemv, Flash, OSS sound server, etc....

even thou its been abandoned by the big players, few still used it.
so will it be an abandonware any time soon(in less than 5yrs)? nope, many people dislike change.
will it be abandonware 10yrs+ time? yes, nothing last forever.

Article title could be made better like "The X.Org Server Is Commercially Abandonware"

All but MATE is actually an active project. Everything else you listed is actually dead. Nobody wants Flash anywhere near their systems, and only fringe schizophrenics use SysVinit in Linux.
You're conflating commercial interest with interest in general. Nobody wants to work on X11, it's just a complete mess. When Solaris of all things has more hobbyist support than X11, you know things are bad.

[angrypie]

Because it's pretty much complete and stable.

The protocol has flaws, but Wayland still is a work in progress, lacking some important features...

(and a secret plot to GNOMize or destroy KDE)

Came here to say this, but GNOME won't remain the only semi-usable Wayland DE for long, they're so far ahead into the game because they started first. Devs will eventually agree on a way to share screens and such.

In fact I think the demise of X will force different minds to some unprecedented collaboration instead of what we had until now, people working around X's limitations and not giving a fuck if other DEs/WMs had to do the same. If that happens we'll see more consistency, radically different DEs behaving more or less the same for arcane stuff (which has been a flaw of the Linux desktop since its inception).

[kurkosdr]

Wayland doesn't support anything, since it is a wire protocol. Most of the existing compositors don't support Nvidia - or the other way around : Nvidia doesn't support them.

What would it mean for the BSD, if X11 is dead? Would they maintain it themselves? Or switch to Wayland based compositors as well? AFAIR Wayland support is in the works for FreeBSD.

Oh ffs, do people still split hairs over the whole Wayland/Weston thing?

It's not like Wayland has a standards body such as ITU which finalizes the standard and then once the standard is frozen multiple entities implement it. Wayland and Weston are more like Windows and win32, they evolve together.

[Awesomeness]

This link says that everything it is just an initial state...

https://wiki.gnome.org/Initiatives/Wayland/NVIDIA

last edited 2019-05-15

Cool

[oleid]

Wayland and Weston are more like Windows and win32, they evolve together.

Sure, but what does weston have to do with the Wayland compositor you're actually going to use, like Gnome-shell, kwin or sway?

[oiaohm]

Sure, but what does weston have to do with the Wayland compositor you're actually going to use, like Gnome-shell, kwin or sway?

Weston Gnome-Shell and Kwin solutions are using libwayland-server. Weston the reference compositor is what is used to work out the reference libwayland-server library. So the behaviour of Gnome and Kwin does partly align with Weston due to common upstream parts. So Gnome-shell, Kwin and Weston are in fact all evolving with each other.

sway is wlroots based.


All major developing Wayland compositors are either wlroots based or libwayland-server based. Since a lot of the behaviour of the compositor comes from the library they are based on there is a lot of behaviour being identical between wayland compositors build from the same base library. So the fragmentation is not as large as it first appears either.