Trend Micro Uncovers Yet Another X.Org Server Vulnerability: CVE-2023-1393

[mSparks]

Lets start off with how you are badly wrong.

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1150

This alteration 2 years if you are using open source driver(amd, Intel, rasbery pi....) The Xwayland latency is 0 or 1. Xwayland 1 latency on open source drivers only happens if application is not using opengl or vulkan correctly in fifo mode. This in time most likely will be fixed with a per application patch in mesa for the open source stack as this is not wayland/xwayland unique problem.

Wayland compositor is also zero because GPU gets pick up the latest buffer instance from the DMABUF when the GPU welds the output together.

Now Nvidia closed source drivers. you don't have the opengl functionality to go zero frame. So this means +1 for Xwayland at times +1 or 2 in wayland compositor now it absolutely suxs. Now note I am writing a min of +2 when using Nvidia closed source this comes important.


No this is wrong. xorg-server baremetal always added 1 frame of latency if using Nvidia..

Open source drivers under x.org bare metal without compositor have the same Xwayland latency of 0 or 1 with the same cause for 1 frame of latency.

Yes measuring on Nvidia hardware you see 1 extra frame difference in most cases between Wayland and xorg bare metal failure to measure closely means you miss 1 extra frame xorg server has on bare metal due to no zero frame functionality.



The first hypothesis you put forwards is totally undermined by facts. You only have 1 frame of latency with Xwayland or bare metal xorg server without compositor and open source drivers if the program is bad coded for the past 2 years. Yes past 2 years on open source drivers no difference.

Maybe Nvidia is now working releasing firmware and other things to open source driver developers because this problem is so core to the Nvidia driver they cannot fix it.

AMD and Intel is currently the low latency solution under Linux and it does not make difference if you are using X11 or Wayland there is no frame count difference..

The difference between Nvidia wayland and X11 performance in many benchmarks is the signature of the fundamental defect in the Nvidia driver. Yes the fundamental detect shows worse under Wayland because zero frame operations are important without them extra frames happen.

PS if you have not worked it out yet by how often I am able to answer with open bugs that you are incorrect that the upstream wayland developers are setting the anti-Wayland people up to have themselves ripped to bits by anyone who knows what is really going on with Wayland by not closing bugs their sites reference. They need to start coming and reading the bugs to find out what the current issues are. One of underhanded features of gitlab is the means to leave bug open externally displayed but to logged in people the bug appear closed if no body posts or modify it.

Very long winded way of admitting you dont like the numbers and facts.
quick and easy measuring is just film on your phone how far behind screen updates are to mouse movements, or record your awesome wayland desktop animating and lets look at any difference frame by frame with the video I just posted, you reckon there is some noticeable difference in favour of wayland, put up or shut up tbh.

The force of denial is strong with this one.

I mean, if you can't, you pretty much prove to everyone reading this thread wayland is an abject failure with no future.

[oiaohm]

Very long winded way of admitting you dont like the numbers and facts.
quick and easy measuring is just film on your phone how far behind screen updates are to mouse movements, or record your awesome wayland desktop animating and lets look at any difference frame by frame with the video I just posted, you reckon there is some noticeable difference in favour of wayland, put up or shut up tbh.
.

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1150#note_836472

Please look at this out the bug report. Note the graphic there. This tells you when events happen even more critically when application sent the event and when it end at screen.

Video recording screen is you just attempting to move goal post by doing something that is totally pointless that does not contain the information to prove anything same with recording my screen with phone or capture device.. Basically you are talking about input latency what point is a youtube video you have no input events to compare to output ones.

About time you admit with AMD and Intel using Xwayland there is 0 to 1 extra frames with 0 being the normal. There is a graphic you can generate that can tell you exactly if you have extra frames or not.

That graphic can be generated on bare metal X11.

Even the recent gnome compositor performance dive this does not result in a difference in performance between AMD bare metal X11 or Xwayland. Xwayland is not the problem and has not been for 2+ years.

Wayland desktop tear free by the graphs that measure latency is less latency than X11 bare metal tear free using the same compositor that the facts of the matter.

Nothing in the video you posted proved anything basically. There was a very critical graph in the issue I linked ot.

Yes generating that graph on Nvidia systems you find the constant extra frame in the X11 server on bare metal. You as frame rates go up in tear free more extra frames on Nvidia solution in the X11 compositor than you see on AMD/Intel solutions with the same X11 compositor. Yes X11 compositor on AMD adds more frames that was noted in the 2021 benchmark I quoted.

Tear free latency is terrible on Nvidia. Tear free latency is poorer on bare metal x11 than XWayland with a decently performancing Wayland compositor that is just the way it is. Wayland solutions have closed up in performance when tearing is allowed.

mSparks; basically ignored your video post because it pointless and proves nothing. Reality you are just use to a system with 1 to 2 frames of latency people who use wayland for a while end up not use to it and really notice it when they move back to X11.

You can have something with 100 frames of latency yet still generate a perfect looking video even moving a mouse around so the video is absolutely pointless...

I mean, if you can't, you pretty much prove to everyone reading this thread wayland is an abject failure with no future.

Read my posts carefully. I have not been attempting to prove Wayland is good ever. If all you have to prove that wayland sux is a video that proves nothing you have not had solid facts to prove Wayland is defective.

Also note I have written many times that if you said Wayland was bad on Nvidia I would not have had a problem that the truth. Yes the claim that Xwayland adds one frame of latancy always that a false claim.

Majority of your points against Wayland have been issues that were resolved years ago or worse faults that have never existed.

mSparks you said Wayland development has been waste of time. Really you are the one that needs to put something up that solid. Anti-Wayland crowd really don't have anything solid to back that claim at all.

Yes there are issues even admit that. Wayland on nvidia is bad but that is because Nvidia drivers are bad and doing up graphs on latency provable bad. There are times gnome/kde compositors have done stupid things but those have done stupid things with bare metall X11 so this is not wayland unique problems.

There is still work required to complete out bridges so that more legacy applications can work. There is still work to add wayland back end to wine/proton to reduce overheads.

There is nothing about current Wayland that says Wayland development has been waste. In fact Wayland development is why we now have graphs systems to track input vs output though the X11/Wayland solutions and what lead to it being found that Nvidia under Linux is no where near as good as it was first believed. Thank you anti-wayland people your complaints causes new tools to be made and the answers of those tools was not exactly what was expected..

[mSparks]

Nothing in the video you posted proved anything basically.

On it's own no, It was up to you to prove the veracity of

Better general performance when using your desktop is not meaningful?

Your inability to show it is meaningful, means we can fully summarise

now you concede wayland doesnt have any power benefits over xorg

doesnt have any performance benefits over xorg

is much less user friendly than xorg for most desktop use, if it even has them as a feature

Users are refusing to use Wayland at the moment because the applications they want don't work.

we fall all the way back to wayland is better because its different, even though it is worse in every imaginable way.

Wayland is dead on arrival because adding extra IPC calls to openGL/Vulkan doesn't give any benefits, and after 14 years of development all of the above isn't expected to change ever.

Wayland is an abject failure with no future.

[oiaohm]

Troll post again mSparks.

doesnt have any performance benefits over xorg .

https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html

Shows the lower latency in tear free over xorg that is a performance benefit.

I have show you there is a performance difference you want to disregard. Common bench-marking suites don't benchmark general desktop usage/Tear free. The people say they find better about Wayland in usage feel is the bit the benchmark suites don't benchmark.

Yes the introduction of allow tearing in Wayland means you are running game benchmark we are allowing tearing so the benchmark runs the same as X11. So no longer measuring the tear free value. The tear free performance is what important for your normal non game desktop application interactions.

There is also document power saving.

Wayland is dead on arrival because adding extra IPC calls to openGL/Vulkan

]

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1150#note_836472

There are benchmarks and graphs that shows this has close to zero effect one you have zero copy buffers. You don't have the zero copy buffers using X11 composite extensions the way the protocol is designed does not allow it.

Now mSparks redo that summarise with a valid link backing each point.

It seams that you add to that summarise list the exact invert of what I have written intentionally.

[mSparks]

Troll post again mSparks.

There are benchmarks and graphs that shows this has close to zero effect one you have zero copy buffers. You don't have the zero copy buffers using X11 composite extensions the way the protocol is designed does not allow it.

Well, around and over the last 5 years all the original developers/authors of Wayland abandoned it.

SRC:

https://github.com/freedesktop/wayland-weston/graphs/contributors

Since then new ones started that began trying to "hack" X11 into it via Xwayland. At best that may match X11, but the norm is to significantly underperform. watched a hillarious video while looking for what others had done, this one is proper funny.

https://www.youtube.com/watch?v=a-Gfpc60cHU

6 minutes 30 seconds of how great it is that it can remove tearing.. 30 seconds outro of how an update that day broke everything.
That was a year ago, my personal experience of Wayland is it has only gotten worse since then.
Oh, and I don't see any tearing in that video I posted of X11 gnome in 04/2023, do you?

It seams that you add to that summarise list the exact invert of what I have written intentionally.

Every time you post some hyperbole you subsequently fail to prove true then try and change the topic when called on it, I conclude it wasn't true. All your doing.

Video recording screen is you just attempting to move goal post

Except I moved them right up close to you, you had an open goal with no defenders for miles and you still missed, if what you were saying was true it would have taken less time to snap and upload a video of it being true than proof read the garbage you came up with in response, right now there is not a shred of evidence you daily drive linux, let alone the wayland desktop you are shilling for.

[oiaohm]

Well, around and over the last 5 years all the original developers/authors of Wayland abandoned it.

Is that the only change the git shows. You did not look closely enough Wayland changes from having commits on weekend and after hours and so on to have majority of commits 9-5 5 days a week. At the same point Kristian Høgsberg Kristensen steps back. Pekka Paalanen from Collabora takes over at that point. Pekka Paalanen is a team leader at Collabora. Please note Pekka Paalanen first work on Wayland is 2011 not as simple to spot this was under a different email account so they had done quite a bit of work on Wayland before being given the lead role.

This is not abandoned this is allowing party with more resources to take over. To be correct after stopping work on core Wayland Kristian Høgsberg Kristensen started doing some work to reverse engineering the Nvidia drivers because Nvidia still at that time was not going to provide Wayland interface.

So not abandoned wayland there were changes back then to free up the core highly skilled people who started wayland to focus on areas that need their higher skills like pulling part nvidia drivers getting the data that allow Redhat todo the GLX-Relay and so on..

The reverse engineering work comes with a price of course. Once Kristian Høgsberg Kristensen took up that role he could not keep on working on core wayland. Clean room legal requirements.

Yes horrible right the major reason why Kristian Høgsberg Kristensen is not head of Wayland development is Nvidia stubbornness that had to be defeated by brute force.

Since then new ones started that began trying to "hack" X11 into it via Xwayland. At best that may match X11, but the norm is to significantly underperform. watched a hillarious video while looking for what others had done, this one is proper funny.

Another lie. Xwayland starts before krh leaves. They did fix the performance issues since then.

Collabora put a team on wayland they have the resources to spend coding up diagnostic tools that Kristian Høgsberg Kristensen could not.

The normal on AMD/Intel and open source graphics hardware is X11 and Wayland solutions to match in X11 performance since particular issue was fixed. Issue that was clear to see with the Collabora made tools.
.

Oh, and I don't see any tearing in that video I posted of X11 gnome in 04/2023, do you?

You can generate output 100 ms + of latency with zero tearing as well. That video shows nothing important.

https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html

Those 2021 numbers are before Xwayland get patched to have a zero frame cost.
Where is you milliseconds of input latency when in tear free mode. This is the performance area where Wayland solutions have been better for a long time. How much latency your normal desktop has.

As I said that video of your is pointless. The video you presented does not counter the 2021 data. You did not set your self up with a input latency measuring device did you then due to machine to machine differences the wayland test and the X11 test has to be done on the same machine or the results are not valid and you have to do the testing more than once for run to run differences.

Why is the desktop not bench-marked because it not as simple as run a script get a result. Bench-marking general desktop performance is setting up hardware to measure latency. Wayland has for a very long time getting better input latency with tear free enabled. Early on before the fix to take Xwayland to 0 frames cost the extra frame there did not matter because default X11 bare metal added 3 frames in tear free and wayland was only added 2.

You still have the problem X11 compositor extensions add extra frames.

X11 and Wayland on tear free performance has improved over time. But we are now to the point X11 protocol is for tear free basically maxed out. There are still a few areas where wayland can get faster. X11 compositor section of the X11 protocol equals bad tear free performance. Yes the performance is how much user input latency you have in tear free mode.

Remember you said for games X11 compositor steps out way. Interesting point is Wayland compositors normally are not stepping out on AMD and Intel but seeing the same performance this is due to working zero frame due to dmabuf zero copy.

Of course if the game performance is dropping because compositor effects are eating up all the GPU time this normally happens be you X11 or Wayland. Why because gnome and kde under X11 might to the application the direct output but that does not mean they stop rendering the off screen stuff..

Extra frames of latency does not equal tearing output.

[mSparks]

Another lie. Xwayland starts before krh leaves. They did fix the performance issues since then.

XWayland didn't get remotely decent GPU acceleration until August 2021, there was a huge song and dance about it.
https://linuxreviews.org/Xwayland_Has_Gained_Support_For_Hardware_Accelerat ion_On_Machines_With_Nvidia_graphics_Cards

You still have the problem X11 compositor extensions add extra frames.

Which are absolutely no problem compared with the myriad of wayland extensions that make say a gnome wayland application unworkable on KDE and vice versa.

There are still a few areas where wayland can get faster. X11 compositor section of the X11 protocol equals bad tear free performance. Yes the performance is how much user input latency you have in tear free mode.

yes, in 20 years, it might be as good as X11 today, whoop stop the presses.

Of course if the game performance is dropping because compositor effects are eating up all the GPU time this normally happens be you X11 or Wayland.

Nope, "By design" on X11 going through a compositor is optional
Either
220px-X_client_server_example.svg.png
or
x-architecture.png

On wayland it is not.

wayland-architecture.png
Xwayland joins those together, the X11 compositor is a Wayland client, all the disadvantages of both, none of the advantages of either.

Extra frames of latency does not equal tearing output.

Not related, the seemingly unavoidable extra frames of latency using Xwayland are just what makes wayland an abject failure which will never compete with xorg-server, and tearing on X11 isn't an issue worth adding extra frames of latency by putting X11 atop of wayland.

Nvidia stubbornness

Blame shifting changes nothing. you can blame Nvidia for wayland being an abject failure with no future all you want, it will still be an abject failure with no future.

[oiaohm]

XWayland didn't get remotely decent GPU acceleration until August 2021, there was a huge song and dance about it.

The eglstreams stuff was scrapped by the end of the same year. So how it it decent now with hindsight what links you are referring is broken garbage.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6429

Yes eglstreams Xwayland was out performed by the year before GLX delay in stability and performance.

Nvidia did not have decent accelerated support at the start 2021.

https://www.gamingonlinux.com/2021/10/nvidia-beta-4952905-rolls-out-with-gbm-for-expanded-wayland-support/

It the end of 2021 when Nvidia accepts they have to follow suite and user what AMD and Intel had been using since 2010. They are still behind with GBM.

2020 with GLX delay then start of 2021 eglstreams then end of 2021 Nvidia accepts they have to support GBM like AMD and Intel had been using since 2010 for accelerated with Xwayland.

XWayland had decent GPU acceleration before Nvidia support and what you use today is the old code base.

Yes there are a lot of early 2021 write up who incorrect presumed the eglstreams issues were minor and since it was Nvidia this was going to be best performing and so on solution. Hindsight tells as now that every eglstreams bit was just a total waste of time.

Which are absolutely no problem compared with the myriad of wayland extensions that make say a gnome wayland application unworkable on KDE and vice versa.

99.9% of Wayland applications don't use platform unique parts of the protocol. Majority of Wayland gnome applications work on KDE Wayland and the reverse.

Nope, "By design" on X11 going through a compositor is optional.
On wayland it is not.

Is the wayland diagram you use current mSparks.

https://www.phoronix.com/news/Mutter-Unredirect-FS-Wayland

The answer the wayland diagrams you are using is not current for how things hook up.

Wayland compositor can be bypassed for output. DMABUF zerocopy stuff again. Wayland compositor can tell the GPU that the Wayland application output DMABUF is the screen DMABUF. Soon as the application does up its output buffer the GPU can display it no compositor interaction.

mSparks by design X11 protocol has tearing. Way to remove tearing use compositor or tearfree driver workarounds both come with performance cost with X11.

Not related, the seemingly unavoidable extra frames of latency using Xwayland are just what makes wayland an abject failure

DO I need to link the bug with the Graph that shows without question that current day Xwayland adds zero extra frames of latency.

https://forums.libretro.com/t/an-input-lag-investigation/4407/1006

There are many studies into this. The big thing is Wayland compositors without graphics driver issues end up equal to bare metal X11 servers without compositors. Of course this means you have all your desktop effects and all your anti-tear features of the compositor with basically no extra input latency.

Please note Wayland compositor and bare metal X11 server without compositor is still slower than applications using direct to KMS that still slower than Microsoft Windows exclusive-fullscreen.

Yes getting general desktop usage where it must be tear free have less input latency is kind of important.

There are ways software can use graphics drivers that add more frames and graphic driver defect that add more frames. Yes some times these defects stack.

mSparks input latency is not a 100% solved problem on Linux. X11 bare metal without compositor is a lot slower than most would presume.. 54ms of round trip latency is called good with 51ms being Microsoft Windows as that one 2022 link showed. So 3ms still need to be removed somehow. Yes that going to require work at the kernel level thinking direct KMS is 53ms.

[mSparks]

Nvidia did not have decent accelerated support at the start 2021.

https://www.gamingonlinux.com/2021/10/nvidia-beta-4952905-rolls-out-with-gbm-for-expanded-wayland-support/

It the end of 2021 when Nvidia accepts they have to follow suite and user what AMD and Intel had been using since 2010. They are still behind with GBM.

But ahead in literally everything else.

Wayland compositor can be bypassed for output. DMABUF zerocopy stuff again. Wayland compositor can tell the GPU that the Wayland application output DMABUF is the screen DMABUF. Soon as the application does up its output buffer the GPU can display it no compositor interaction.

If that mattered then X11 would not still outperform it often and in meaningful ways. It does so it doesn't.

What part of vulkan/opengl is DMABUF anyway? Isnt that a software rendering thing? Is the wayland compositor relying on the CPU for a chunk of its rendering?

[oiaohm]

But ahead in literally everything else.

No the EGLstreams version of Xwayland had Nvidia losing in benchmarks to amd and Intel at the time. Some times Nvidia is just massively behind..

https://www.phoronix.com/review/fedora_20_wayland/2

Remember phoronix bench-marked Xwayland performance for a very long time.

What part of vulkan/opengl is DMABUF anyway? Isnt that a software rendering thing?

https://www.kernel.org/doc/html/next/driver-api/dma-buf.html

dmabuf is a memory management thing used by software rendering and hardware rendering in the open source space.

Yes Nvidia added need to provide file handles to opengl and vulkan in 2016.

https://registry.khronos.org/EGL/ext...buf_import.txt one problem dmabuf was added to opengl as an optional officially in 2013.

Yes mesa prototype opengl extensions for dmabuf takes you back to 2010. Since mesa drivers were already using dmabuf the file handles were just dmabuf file handles.

DMABUF is where lots of the work is to lower the latency.

mSparks find me a benchmark that shows that Nvidia has the best in latency on Linux(you will be in for a surprise). At some point you should wake up we have lots of benchmarks but most are not measuring something important. Nvidia reflex levels out performance does not go for the lowest possible latency.

Yes Nvidia has been able to get the max frames per second but has not be able to get the lowest latency on Linux for over 8 years now. Yes the lower frame-rates of AMD people presumed this had to equal lower latency. AMD has had a lot lighter frame output cost on Linux for quite awhile yes linked to DMABUF work.

Latency is a figure you have not wanted to talk about but its the key point. Latency difference is why some users say there general desktop usage with Wayland feels way better.

The problem here is how to improve the tear free Latency and the tearing Latency.

Also its important when talking about latency not to presume like you did that there had to be extra frames. Xwayland processing at worst added less than 0.1 of a frame of latency. When a defective driver can add up to 10 frames of latency Xwayland cost is close to nothing.

Remember DMABUF is a built into the OS kernel as OS kernel feature.

Wayland started with GEM handles that were a predecessor to DMABUF. Same thing GEM is a kernel support buffer management system that was designed to work between the GPU and CPU and between kernel and application like DMABUF is. DMABUF also picked up direct GPU to GPU as well. DMABUF is still being improved.