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

[mSparks]

Except not everyone having this problem.

Not everyone cares about the problem (including you), that isn't the same thing.
For example I see

https://linux-gaming.kwindu.eu/index.php?title=Improving_performance#Wayland

X11
X11 is currently the best choice if you want minimal input lag.^[10]

The best way to achieve low input latency on a Wayland compositor is to enable Freesync or enable tearing updates.

Is that one of those "anti wayland" sites you were talking about?

X11 has no tearing or latency issues, the guidance for wayland seems to be "pick one" or buy new hardware.
Anybody who actually takes it seriously uses X11 and will always use X11, any legacy wayland code worth reusing will make it into X11 compositors eventually I'm sure.

[oiaohm]

Is that one of those "anti wayland" sites you were talking about?

X11 has no tearing or latency issues, the guidance for wayland seems to be "pick one" or buy new hardware.
Anybody who actually takes it seriously uses X11 and will always use X11, any legacy wayland code worth reusing will make it into X11 compositors eventually I'm sure.

No this is your normal anti-wayland person not reading the reference and the site you used is unfortunately deceptive the information there if you don't read all the cited links and the page completely.

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

Yes its 2021 that say X11 better than wayland but the reference gives some very strict limitations.
As soon as you are running x.org server on bare metal with X11 compositor you are performance killed. Yes default xfce install loads a compositor so now you have worse latency than Wayland solutions.

Yes x.org server + X11 compositor always loses to Wayland Compositor + XWayland in latency and that was proven in 2021.

If you require the absolutely lowest latency possible though and don’t care about screen tearing then X without compositing, with VSync disabled is a better fit for you.

Yes what I just quoted is what really should have been on the site you were reading not to be deceptive. Xorg-server on bare metal solution in 2021 could only have lower latency than the Wayland solutions if all those conditions are meet.

The claim X11 has no tearing issues is false the only way X11 solution can be faster than 2021 Wayland solutions in latency because of tearing.

https://www.phoronix.com/news/Wayland-Tearing-Control-Proto

Wayland allows application to say to compositor this application need really low lattency render this application with tearing and everything else that did not request this is rendered without tearing.

Yes this 2022 extension to the Wayland protocol comes about due to the 2021 research into the problem.

If your interface has tearing you should to obey most countries health and safety laws and display "Photosensitive seizure warning" due to the flicker tearing can cause. Yes one of the reasons why xorg-server bare metal desktops without compositors are not allowed in most business settings. Who pays for commercial Linux distribution development that right business.

Yes application that asks permission under Wayland to tear should have already displayed warning.

mSparks today 2023 wayland solutions in tearing allowed mode guess what no latency advantage at all to xorg-server baremetal.. Yes there is a patch in 2022 to Xwayland that make freesync under Xwayland for latency absolutely identical to bare metal x.org server.

Of course those tests are with AMD.

mSparks X11 it is truly pick
1) low lattency with tearing
2) no tearing with desktop effects and other things but with major latency issues.
As all or nothing options.

Also do notice something Wayland compositor is on and application be it Xwayland application or native wayland application can use freesync but you load compositor into X11 server bare metal and means to use freesync goes away and other options go way as soon as you enable X11 compositor..

Wayland does allow you to mix and match and get the best of both worlds since the tearing extention.

mSparks like it or not even the 2021 numbers that the site you reference is based on does not show wayland solution have a major latency problem. In fact it shows that X11 bare metal with a X11 compositor has major latency problems way worse than any Wayland solution on AMD, Intel and other open source GPUs. Yes 2021 results only way xorg server bare metal can be faster is have tearing that not acceptable in the workplace.

There is another person who measured the performance over head of turning on Intel and AMD tearfree under xorg-server bare metal and put this head to head with wayland solutions guess what at best equal in performance to wayland solution but most cases worse than Wayland solutions. Yes Intel and AMD tear free options under xorg-server is better performing than loading X11 Compositor.,

mSparks with current day Wayland with open source drivers its fairly much what latency issues they don't exist for most users and you have have lower cost for a totally tear free experience using Wayland than using xorg-server bare metal and you can selectively get a tearing experience for lower latency.

Nvidia users you are just totally screwed over because Nvidia driver development is so far behind for Linux. Yes Wayland and VR users are both stuffed over by Nvidia drivers under Linux.

mSparks I do get really sick of people attempting to be anti-wayland going around claiming total false hoods about X11. X11 bare metal you cannot have low latency and tear free at the same time on the same screen it just cannot be done.

You can have tear free and low latency on the screen at the same time with current day Wayland. Yes different application Windows under current day Wayland can be tear free and low latency(tearing allowed).

[mSparks]

No this is your normal anti-wayland person not reading the reference and the site you used is unfortunately deceptive the information there if you don't read all the cited links and the page completely.

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

Yes its 2021 that say X11 better than wayland but the reference gives some very strict limitations.
As soon as you are running x.org server on bare metal with X11 compositor you are performance killed. Yes default xfce install loads a compositor so now you have worse latency than Wayland solutions.

No, even gnome mutter supports unredirecting now, so X11 DOES NOT RUN IO through the compositor - compositing is optional with X11, it is not optional with Wayland. You are talking shit.

where wayland & xwayland is incapable of achieving both >60fps and <10ms input latency, which makes them all unusable

I read the reference site, it said wayland was at least 5 times slower than the <10ms legal requirement for a certified flight sim, with mean latencies generally in the 50ms range, slightly better than I have seen recently, but then it was also written before the recent regressions (coming, presumably, from it not being seriously tested any more).

mSparks I do get really sick of people attempting to be anti-wayland going around claiming total false hoods about X11

You probably shouldn't have done such a good job of convincing me wayland is shit then, I mean, a week or so ago I was sold on the whole "it will eventually replace X11" meme. Now it's pretty obvious wayland is DOA, Ubuntu abandoned it for Mir then merged any nice wayland stuff into X11, xfce dont see any value in wasting time on it. KDE and Gnome are putting some time in it (it's not without value) as a nice "alternative option". But any serious players (e.g. google) outright reject any kind of support for it. might as well just move on, cos this dead horse is well and truly flogged.

[oiaohm]

No, even gnome mutter supports unredirecting now, so X11 DOES NOT RUN IO through the compositor - compositing is optional with X11, it is not optional with Wayland. You are talking shit.

No I am not. There is another set of tests done by that same person. unredirecting does not restore xorg-server performance back to what it was before you loaded the compositor.

I read the reference site, it said wayland was at least 5 times slower than the <10ms legal requirement for a certified flight sim, with mean latencies generally in the 50ms range, slightly better than I have seen recently, but then it was also written before the recent regressions (coming, presumably, from it not being seriously tested any more).

Problem here is repeat self here does not change facts.
where wayland & xwayland is incapable of achieving both >60fps and <10ms input latency, which makes them all unusable
This is not true and the issue that you think that tells you this is you cheery picking and getting a false picture.

https://github.com/ValveSoftware/gamescope/issues/734

This bug has gamescope achieving a stable 120FPS by setting a frame rate limiter set 240. But with that program it does stable 60 and 90fps no problems.

Wayland and xwayland is capable of achieving more than 60FPS and under 10ms these days and has been for years. Problem comes what does the game/program need to see so it perform how the user wants. Its not strange with some programs to have to set the rate limit to twice what you want.

As you start going though the gamescope rate limiter bugs it a random mess. Some programs happy do up 240/300 FPS and cap out high end monitors without lieing to them if you have the hardware to drive that. Others you need to fudge the rate limit information. Yes games that under perform under X11 bare metal that to get them to run at what you want need to be informed that the framerate is double what you expect gamescope allows.

Remember what I wrote about game engine event loop for user input at times being based on FPS of the output. Rate limiting yes it can save power by not rendering frames users will never see but it also can kill game/application performance if the user input event loop is directly linked to output FPS. Yes this rule applies be you doing rate limiting by gamescope or frame rate limiting on Windows using Nvidia or AMD driver tools.

Really fun is the fact that someone who does not have a high end monitor downloads game attempts to play it and the game unplayable it can be because they have like a 60hz monitor and if they can frame-rate lie that they have faster monitor the game input system will start behaving correctly. Yes problem under windows you cannot lie that you have greater than what you have. Gamescope does support claiming to have a faster monitor than you really have as well.

https://bugs.kde.org/show_bug.cgi?id=423230

Guess what one of the bare metal X11 problems is that the wayland solutions don't have.

[mSparks]

Really fun is the fact that someone who does not have a high end monitor downloads game attempts to play it and the game unplayable it can be because they have like a 60hz monitor and if they can frame-rate lie that they have faster monitor the game input system will start behaving correctly. Yes problem under windows you cannot lie that you have greater than what you have. Gamescope does support claiming to have a faster monitor than you really have as well.

never thought of it that way, yeah, I guess the 99.9999% of users who have a 60Hz monitor are going to stick with X11 until they upgrade to VR.... when they will stay on X11. OTOH there was someone thinking wayland had a future, but that pool is likely shrinking fast.

No wonder all the wayland maintainers left with no weston commits since like December.

Just face it, you were lied to, wayland is almost as dead if not more so than Mir and X11/Xorg is very much actively maintained and supported as much as a fully mature display server can be.

[oiaohm]

never thought of it that way, yeah, I guess the 99.9999% of users who have a 60Hz monitor are going to stick with X11 until they upgrade to VR.... when they will stay on X11. OTOH there was someone thinking wayland had a future, but that pool is likely shrinking fast.

Please note you can run gamescope without a rate limit. That gamescope bug over rate limit did not apply to a person with a 60 Hz monitor.

Now having gamescope where you can say ratelimit=120 and hide that the monitor is 60Hz lets user play more games than they would have by just using x11 while only having a 60hz monitor.

Ratelimit option of a gamescope is a double way workaround.
1) cut the frames a game is rendering to save on power/heat... by telling game it has less than what it really has. Sometimes this can sort out game frame rate pacing issues.
2) tell game that it has more than what it has so it behaves right. So you have a 60hz screen you want to tell application it has 120hz or more so game input system works..

But ratelimit option is not without it possible adverse side-effects. Please note by default gamescope does not apply a rate limit or hide the monitor hz instead lets the application get the monitor hz and do what ever it thinks fit.

Rate limit is a special option of gamescope users don't use in most cases..

To be correct Xwayland from some distributions does have a hard set 120hz rate limit at the moment. Its not a rate limit that need to be there it just done for their issue handling. If something is running at 120hz exactly it has to be Xwayland. 120hz monitor does not run at exactly 120hz.

The problem has not been at 90Hz for over 2 years now. Only bugs opened from people hitting the 120hz and those using wine and proton these days. Of course those will go away once wine/proton gets a wayland back end that works.

Every 2-3 years they have been changing the Xwayland agreed default rate limit in 30 up steps. Yes it started at 30fps then stepped up to 60 then 90 now 120 we are coming due for 150.

See problem you went looking for 60 as point of problem it has not been that for about 5 years. Yes there is ways to disable Xwayland default rate limiter.

Different matter if you had been complaining that you were sick of Xwayland being intentionally crippled to 90/120hz without any really good due cause other than being a pain in the ass to attempt to force people to update their programs to support Wayland.. 90-120 means you used Wayland some time recently correctly and noticed where the performance limit in fact was.

No wonder all the wayland maintainers left with no weston commits since like December.

https://gitlab.freedesktop.org/wayland/weston

What the hell are you talking about. There was only been at least 1 commit to the weston code base every single working day 2 years. Yes 5 days a work money to friday with sat and sunday off all the perfect sign of team paid full time to work on something. You can even work out the time time zone/country.

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

Do also remember people say that moving around their desktop in general under Wayland feels better. Yes that is backed by the 2021benchmark that when X11 server has compositor on its slower than Wayland.

[mSparks]

Please note you can run gamescope without a rate limit. That gamescope bug over rate limit did not apply to a person with a 60 Hz monitor.

That's what I said, pick tearing or input latency of at least 32ms. (and more like 50ms) or buy new hardware.

60fps vsync 10ms input latency is the norm on xorg, it seems like cannot be achieved on wayland?

anyway, you still seem to think that wayland is offering something:

Do also remember people say that moving around their desktop in general under Wayland feels better.

a year ago, before the regressions, before they found that Xwayland actually adds a ton of input latency and reduced performance.
Ive not seen anyone say anything nice about it since, even you.

You can't provide one, recent, practical example where wayland is meaningfully (say at least 20% difference) better than xorg?

What the hell are you talking about. There was only been at least 1 commit to the weston code base every single working day 2 years. Yes 5 days a work money to friday with sat and sunday off all the perfect sign of team paid full time to work on something. You can even work out the time time zone/country.

I was going off

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

looks like they moved to gitlab

[oiaohm]

That's what I said, pick tearing or input latency of at least 32ms. (and more like 50ms) or buy new hardware.

Wayland without gamescope rate limiter at play and without some bug(that are basically fixed) you don't see high input latencies at all.

60fps vsync 10ms input latency is the norm on xorg, it seems like cannot be achieved on wayland?

Wayland achieves this on Sway/Kde/Gnome... all the time so basically everything bar gamescope rate limiter but there is a reason for this.
There is a very big difference between refresh rate and frame-rate limit.

Gamescope rate limiter is strict. AMD and Nvidia and Intel GPU when you set refresh rate is not. Gamescope make the behavior in fact as per opengl/vulkan standard. That if a monitor is only 60 frames per second there is only 60 output buffers per second. Decides not to render one of those one of those buffers to user sorry you lose some FPS.

Yes sending the message not to display this buffer by specification should past frame remaining on screen and only display next frame when the next frame cycle comes around be thankful gamescope is not this strict. There is a different command to update buffer.

Gamescope equals games must do their resource management correctly or it will break program when person sets exact limit. Games that have their event loop working off that they can generate unlimited number of output buffers only instead of own back buffer copies it is again I will break you again this opengl and vulkan specification to be doing this.

Lets say you are on a embedded GPU like that you find on raspberry pi 4. Guess what 30/60/what ever the monitors hz is that all the output buffers you have. Yes lot of these are strict where you decide not to display output buffer this will cause frame to stay on screen for 2 instead of one. This has been a problem for those using single board computers. If valve long term plan includes using hardware that is not X86 with GPU vendors you have most likely never heard of crushing this out of specification behavior is in Valve best interest.

Remember gamescope runs nested inside X11 so when you are running games with steam under X11 you can also be coming face to face with gamescopes strict rate limiter that is still less strict than what the opengl and vulkan specification say it should be.

You have to be aware some projects leave a bug open for 3 years after they have resolved the issue to let the person who opened the bug come back read the fix do a test and close the bug. This leads to lots of open bugs existing for faults that have not existed for years.

anyway, you still seem to think that wayland is offering something:.

Something people notice a lot is when using general desktop as when the system has to be tear free to be legal is always less latency than the X11 options. Yes this less latency is backed by 2021 benchmarks and others.

a year ago, before the regressions, before they found that Xwayland actually adds a ton of input latency and reduced performance.
Ive not seen anyone say anything nice about it since, even you.

This is a common half understand. What they found was not a ton of input latency its the 2021 paper lot of those claims are based on.

Wayland first objective was as good of tear free as possible. Wayland has 100 percent achieved this. Wayland solutions are the fastest tear free solutions you have on Linux. Legally for business workstation usage that is the most important figure so course since most Wayland developers(not core here KDE/GNOme... in general) are full time paid employees developing solution for businesses this has been their focus on at first has had to be tear free. Yes it was only 2021/22 when they decided to bother about the fastest possible output legal or not that is have tearing.

When your objective is to get as perfect tear free desktop as possible allowing any tearing at all make spotting defects hard. Yes tearing issues that have been going not noticed on xorg bare metal got noticed and reported and fixed in Xwayland then fixed in xorg bare metal because tearing was out of place on the Wayland desktop.

Xwayland performance other than true bugs has not has major issues and the bugs have turned up are not exactly abnormal either. Over X11 history different versions of xorg-server and Xfree86 on bare metal have had same input latency bugs. The process of cutting down Xwayland by removing xorg-server input driver subsystems for loading up X11 user space input drivers and only using libinput has not always gone perfectly to plan. Yes every major refactor or xorg-server and Xfree86 bare metal input stacks never went perfectly to plan either. There are basically set of bugs you should expect to turn up every time xorg-server bare metal or Xwayland decide to optimize their input stack. Xwayland seen a few more that normal but its also done lot more work in input area than normal over the past 12+ years.

You can't provide one, recent, practical example where wayland is meaningfully (say at least 20% difference) better than xorg?

Better general performance when using your desktop is not meaningful? The people liking Wayland keep on saying the same things smoother less jitter desktop performance. 2021 does not show up as 20% difference in benchmarks but it big enough that those that stay around using the desktop for work not just jump over to wayland to benchmark a game or something to go hey Wayland does not work that they notice and is provable by benchmarks as existing.

For general desktop users x.org baremetal is behind area of usability due to how poor it tear free is resulting in reduced desktop responsiveness.

looks like they moved to gitlab

That not the case they have moved. Freedesktop migrated to their own self hosted gitlab in 2018 and had a different self hosted solution before that. Github has only ever been a mirror of freedesktop.org stuff with the development always done in the freedesktop data center(yes they have their own data center that is in fact in the freedesktop name). December last year since freedesktop/x.org is linked to a big foundation SPI results in github being pay us money and SPI that manages Freedesktop/x.org money and assets was bugger that we will just not mirror to github any more.

X.org and Wayland developlment work as been done in the freedesktop data centre for ages. X.org moves to freedesktop datacentre in the mid 2000s.

Yes there has been a problem with people opening bugs on github and not getting them attended to with github as well because none of the developers of x.org or wayland in fact use github. Yes freedesktop gitlab it their own run instance of gitlab on their own hardware..

Remember its not gamers who are funding wayland development. It business who would have a stack of computers with Intel integrated GPUs that output to be allowed has to be tear free for business usage as this is government regulator enforced requirement. Yes the business usage they have more Intel GPU to deal with than Nvidia ones by a large margin. This has lead to issues with Nvidia.

Nvidia dominance in gaming and specialist usage they are use to being able to throw their weight around and do what ever they like most of the time then they hit the Wayland developers that gaming and specialist usage means nothing general usage must work perfectly as that is what the Wayland developer are funded to make. Yes 10 years of dispute before Nvidia finally accepted were they in fact sit in the pecking order of only have 17% voice at most so need to toe the line including put up developers to have a voice. Of course that puts Nvidia 10+ years behind everyone else.

mSparks yes truly Wayland core developers could not care if Nvidia solutions don't work at all because Nvidia solutions are such a small percentage of the systems they are designing for. Yes gamers Wayland core developers mostly will only care steam because valve is providing some developers to have voice.

Wayland is the future coming its well funded and is not going to stop. Motivation/employment of the Wayland developers have them with particular order of priorities and they are working down that list. That list of priorities put tearing high performance output at close to bottom list. Yes extention to support tearing added wayland protocols in 2023 is getting to bottom of list. Also down at bottom of list is total automation of desktop.

[mSparks]

Wayland achieves this on Sway/Kde/Gnome... all the time so basically everything bar gamescope rate limiter but there is a reason for this.
There is a very big difference between refresh rate and frame-rate limit.

No it doesn't, on xwayland input to the application is a frame behind the current frame as it goes through the compositor buffers, 60fps is 16.6ms, so any input generally takes two to three of those to hit the screen - 32 to 44ms, plus the 5 to 10ms latency generally in the OS reading the IO puts puts IO latency in the 50ms range.

on xorg all you have is the 5 to 10ms latency generally in the OS reading the IO, dumps it straight in the application.

I've measured this, it matches what other people are measuring and complaining about including what you linked earlier (except his X11 measurements are really high, but probably not unredirected).

Better general performance when using your desktop is not meaningful?

Not seen it myself, but sure, here is a video I recorded while discussing with someone why Linux/X11 rocks and windows doesn't

https://www.youtube.com/watch?v=nnDYHSFFMOA

What is this "Better general performance" to measure when logging in to wayland and I'll take the numbers, can't screen record the wayland session of course, because that doesn't work properly.

Or don't you like the numbers and facts because they undermine your hypothesis?

[oiaohm]

No it doesn't, on xwayland input to the application is a frame behind the current frame as it goes through the compositor buffers, 60fps is 16.6ms, so any input generally takes two to three of those to hit the screen - 32 to 44ms, plus the 5 to 10ms latency generally in the OS reading the IO puts puts IO latency in the 50ms range.

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.

on xorg all you have is the 5 to 10ms latency generally in the OS reading the IO, dumps it straight in the application.

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.

Or don't you like the numbers and facts because they undermine your hypothesis?

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.