Hello, this is my website and I do not know what you mean by this. If you give me technical details (like the subnet your operating out of), I can take a look at it.

My webserver is using crowdsec (https://www.crowdsec.net) to ban malicious IPs and I would guess that you are somehow unintentionally affected by this.

You can also test your IP by entering it into the crowdsec website to see if it is affected.

> These results will get reported back to the graphics software authors and the distribution packagers and the ecosystem will improve. There's no sense with Microsoft that kind of improvement is possible.

It wouldn’t surprise me if Microsoft could turn a knob and get telemetry data from millions of devices, and feed that back to the software graphics authors.

Certainly both Intel (https://www.techpowerup.com/312122/psa-intel-graphics-driver...) and Nvidia (https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) collect such data themselves (opt-in in both cases, so they may not get much data from the most hard-core gamers)

> results will get reported back

Even better, most of the tech stack is open source and contributions are welcome!

> But surely, latency is all about "placebo" and "vibes" and "feel" is it not?

Not sure if I can follow but...no?! My first TFT-TV had 2 seconds input lag. Impossible to play video games on it. That has nothing to do with feelings.

Already 10ms delay has a measurable effect: https://www.youtube.com/watch?v=5qjSGEOEaXo

Whole 3.13ms? Man idk shit’s unplayable now.

When rendering 60fps on a 60Hz display every frame takes approximately 16ms to render. Then you have to add TV latency that’a probably around 20ms unless you have a very nice OLED TV. Wireless controller latency is around 8ms I think? Then your imperfect human brain adds even more latency especially when you’re tired after work. That 3ms is not perceivable. Make that 5ms even. Nobody would be able to tell a difference in a blind test.

> But surely, latency is all about "placebo" and "vibes" and "feel" is it not?

In the case matters most, it's not a placebo.

Imagine 2 FPS players with identical ability who play against each other. If one has a system with 4ms latency and the other has one with 5 ms latency, the former will statistically have the upper hand, even if the players can't, in isolation, notice a difference between the 2 systems.

I'm not sure I understand. If X11 software requires a X11 server and you have a Wayland compositor, how do you "avoid" XWayland?

I think it depends who it is making noise. There are some famous Oculus-era stories about John Carmack tracing display latency issues and then writing lengthy screeds to Samsung engineers to get them to give him lower level access.

I bet if someone like him made enough noise, people at MS would pay attention.

> One thing that's lovely about Linux is this kind of analysis is not only possible, but meaningful.

If only they'd actually DO something with this meaningfulness. I love and use Linux as my daily driver, but desktop environments and everything around it have become so complicated yet worse than before.

In the past a simple config file with intuitive setting names inside of them could make you do anything you wanted.

Today they have all these layers of abstraction for themes, icon sets and light and dark mode and what not, but almost NO combination works!

If you set light mode, you'll get some light gray text on lighter gray background somewhere, but if you use dark mode, then you'll get some black text rendered on a black background elsewhere. And even if not involving light or dark mode, same misery with whatever themes like "Adwaita" and others, some things will work in one, other things in another, I've seen a PDF viewer that made everything black text on black background in some desktop themes... A PDF viewer can't even independently choose its own text and background color without the desktop environment messing with it?

No theme I found anywhere has _well visible_ scrollbars, they all seem to love making them as subtle as possible so you can hardly see where your scroll position actually is. No theme I found anywhere has a _clear visual distinction_ (different color, not just a subtle shade difference) for the selected window vs the non selected ones. This would be _extremely_ handy for knowing in what window you're typing now, even windows 3.11 got this (and the scrollbars, and the ability to customize your colors) better

While not latency, it's still a thing they just can't get right, and when things were less overdesigned it actually worked better, so what was all this for?

Some things do indeed improve, but some other things require a massive effort that no hobbyist or small company can make happen.

This is most obvious in places where a lot of coordination is required, for example in supporting proper color correction throughout all applications, or decent support for advanced printer functions.

There are many incremental changes, but we often get stuck in local minima for years.

Still, I personally like that one can (relatively) easily watch what happens under the hood. It's not entirely clear to me why Windows and MacOS must remain closed source.

This kind of thing is certainly possible under Windows - you can basically patch any kernel API call, replace any COM object instantiation, install filter drivers that intercept any request to and from a device, replace userland DLLs with your own.

It's really scary what you can do, to the point that I often asked myself 'why allow this?' - seeing as hits on certain APIs took me to blackhat forums and articles about writing exploits.

>give Bazzite a whirl

I never really understood Bazzite's immutable fs thing. Can one install standard dev stuff (i.e. compilers, ides, etc) easily under bazzite?

This use case is the main reason why I lean towards maybe using cachyos

Not Microsoft but Battlenonsense investigations on latency did get Nvidia to create reflex.

Can't say that I agree. I play rhythm games on a national level and benchmarking and reducing input latency is very important in those games.

The games I play (ITGmania) measure accuracy to the tenth of a millisecond, any fluctuation in your hardware latency can ruin your scores and nothing really is more annoying than an inconsistent setup where the latency change between or during a session is absolute hell.

Vibes and latency don't belong in the same sentence at all imo.

gamescope is a custom wayland compositor that Valve built for gaming... In steam big picture mode there is no xwayland or anything, just gamescope.

What you are reading from the readme notes that it calls into xwayland only when gamescope (wayland compositor) is nested within another compositor (say kwin or mutter).

gamescope itself is wayland only, and when run on SteamOS is has no xwayland latency...

> I often see people targeting frame rates way beyond their display’s refresh rate

Could this be to reduce input lag?

Xenocara does it better than XLibre.

Hi, OP here. I just made sure no other user space application were running. Something that basically can be reasonable expected by a person that cares about game performance to do. For example, no one would stop sshd before their gaming session, but closing a Browser is reasonable imo.

That said, this is a pure gaming PC with a Desktop Linux installed, it's not like there's a lot running on there in the first place: no 5 random docker containers, no AppArmor and nothing in kernel space other than what comes by default with CachyOS.

As far as I'm aware, you get marginal FPS gains switching kernels. It helps some. It's just a matter of whether the effort is worth it to you. The main change is the scheduler: rather than trying to evenly distribute CPU time to processes, it will prioritize bursty processes.

I've been a fan of Hyprland for gaming so far. Much more configurable for things like VRR/tearing and other precise tweaks via Gamescope than when I was on AwesomeWM with X11. Been especially nice having Lua for configuration, which finally feels very familiar with my AwesomeWM roots.

That's awesome, odd that I did not come across your project when i was researching this. I'll make sure to read your posts and source code.

I guess you'd feel the same in i3 or Xmonad as well.

the statements of wayland being slow or not need a lot of context: what version of the game they played, the display server, the game settings, the display server settings, the monitor's feature set, the video card's feature set, the video card driver version, etc.

> it starts collecting samples from the photodiode (every ~24 µs).

They also have repeated measurements which improves the precision.

OP here, thank you for the feedback. I will keep it in mind for the next time I'm soldering something.

It's defective by design, in a DRM kind of way. It's designed to lack features and make them difficult to implement.

Yep, OP should certainly retest under gnome. Im not in the weeds myself but I get the vibe that gnome's wayland compositor is somewhat faster and more carefully designed than kwin (at least, Emacs in pgtk mode does substantially better under gnome, whereas on Kwin it uses substantial cpu when scrolling and even lags a bit at high resolutions)

At 60 Hz, there are 16.6 ms between frames, so the ~3 ms improvement from not using XWayland would be very hard to notice visually. Where it can make a difference is that some competitive FPS games have some kind of client side hitscan or lag compensation and often play at high refresh rates, so there it can actually matter that their system reports to the multiplayer server that you clicked in the right place a couple of milliseconds earlier.

Yeah, this particular experiment doesn't reveal much because the Nvidia driver is a black box. We know in the past it used its "composition pipeline" in Wayland situations, and that was a particularly noticeable increase in latency. Plus, for a while the Nvidia driver also was stuck on software cursors. And even on the DRM path the big two compositors only updated input once every frame, which was the reason for it "to have much worse input lag."

edit: I should also point out the mouse acceleration curve, which if you don't fix it is different between X11 and Wayland compositors. That really messes up the "feel" of things.

I have found that input latency is a LOT more acceptable with a controller than it is with a mouse.

Playing a cinematic game with a controller (especially with auto-aim) at 30FPS with vsync is fine. Playing a first person shooter with a mouse, or a game where you control your camera with a mouse, at 30FPS with vsync feels very bad.

That's my theory on why the priorities are different, at least.

Because when it's done right it's not the compositor/display server that's the bottleneck.

Consoles are more and more supporting VRR, as are televisions.

But yes, given the limitations of the hardware, they often offer two modes - a high framerate but lower quality mode and a high quality but lower framerate mode.

>I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.

Pixel refresh is only one part of latency. A higher framerate will lower several other parts of the overall latency. Monitors Unboxed has charts that visualize the amount of latency for each step.

Running above the display refresh rate is only decent when you are wayyyy above it, at least double. If you have a 120hz display and run something variable around 150fps, its much worse. But 500fps does help, you're basically seeing more recent frames as it scans the screen.

It's chronoception effect, not placebo effect. Standard literature claims humans can readily visually perceive 60-90Hz, and perhaps somewhere 500-1000Hz for ghosting. Note that all this is somewhat tangential to the article which focuses on _input latency_, I think the author is driving the high refresh just to minimize _output latency_ as much as possible from the test.

> Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.

In video games you essentially have one giant loop that runs every frame (today it's more than that, but at its core it's still that). Producing frames faster than the display’s refresh rate can still reduce input latency because the next display refresh is more likely to use a recently generated frame. It does not necessarily mean the game receives more input events, but it can process and reflect those inputs sooner.

Not placebo, but diminishing returns become significant, and the benefit depends on frame queues, VSync, VRR, whether the game is CPU- or GPU-bound, and how its input and simulation loops are designed.

Framerates beyond your display's refresh rate are not completely pointless, though a bit wasteful: they do mean that each frame as it is displayed shows a more up-to-date representation of the game state than if your framerate is matched to your refresh rate. In principle you don't need to render the excess frames: ideally your frame time is predictable enough you can kick off the render just before the display refresh, but the penalty is that if you miss the deadline you get some pretty jarring jankiness.

Clicks and mouse movement do have different latency, but it doesn't matter for this test. The click is the constant part to show relative positioning of X11/wayland/low latency/vrr/etc. The relative performance should be the same ranking for mouse movement, just with different exact values.

There you go then. Thank you for confirming my determination of IP blocking. The archive link above may work for the users you censor.

Paying $1900/month for an IP address blocklist for a website? Yikes.

With the exception of XWayland, all of the tests had input latencies within a very small range. No human could tell them apart by those latency differences alone. I would be amazed if someone could notice the 3ms difference jump to XWayland.

The difference could be much larger on a slower monitor. However the differences between Wayland and X11 as protocols is negligible. XWayland as an implementation looks to have a limitation.

I moved to OpenSuse and have the same experience/opinion. The only caveat I had in Wayland is Game Streaming. Sunshine/Moonlight work but the input lag is noticeable and there are artifacts in the game. I go back and forth between X11 and Wayland just because X11 better for game streaming but in time I'm sure I'll go full-time into Wayland.

If I understand the semantics of it all correctly, in that sense, there is no such thing as "Wayland". It is all a little bit confusing compared to the X11 ecosystem.

You don't run GNOME on Wayland. You run GNOME's Wayland compositor, which is an entirely different implementation than Plasma's Wayland compositor.

Question, does your monitor have a KVM? Cause I definitely notice this behavior, even on windows and os x with my monitor. I believe it was the same way on linux as well but it's been a minute since I used linux on my desktop

That’s interesting. Hyprland, spartan? It’s the fancy everything-and-the-kitchen-sink tiling WM, isn’t it?

> and noticed that significant lag

Only xwayland showed that result. The difference was only a couple milliseconds. That’s in the range where I start to doubt that people are feeling the latency difference. If it was 10-20ms I could believe it, but not when it’s a couple milliseconds.

The author of this post did a good job of getting all of the other confounding settings out of the way. It’s possible that the people complaining that Wayland was slow were starting from an unoptimized situation and as part of switching to some low latency variant they set all the correct settings.

You can't just test one wayland compositor and talk about the performance of all wayland compositors. They're vastly different, especially when it comes to the extensions to wayland needed to handle input devices (ref: https://wayland.app/protocols/). It's not like how xorg is the standard strong reference implementation for X11 everywhere that works the same everywhere.

What's probably happening is that other wayland compositors are slower than KDE Plasma wayland which he tested. And people report that experience. Some other wayland compositors might even be faster than plasma. But what is for sure is that every wayland is very different from every other wayland.

This is an annoying style of argument from Wayland fans.

Wayland fan: You need to switch to Wayland. X is deprecated and has been for years! Wayland is the future.

User: Okay, I tried, and it's broken/worse.

Wayland fan: No, you don't understand, Wayland is just a protocol. It's your implementation of Wayland that is at fault, not Wayland itself! Wayland is still great!

User: But X was working fine...

I've been using Linux since the mid 1990's. I'm no newbie to any of this. I literally can't tell the different between X11 and Wayland when using either of them and I don't care about all the arguing. This is just Vim vs Emacs and Gnome vs KDE all over again. At this point when I see people complaining about it I just click off the page. It's all stupid and pointless.

Isn't Wayland always one frame delayed compared to Xorg to avoid tearing or has that been changed? If so, his very high refresh rate would minimize that effect

AMD's Mesa drivers are better, but if you already have an Nvidia card then you can still use it just fine with Wayland.

The biggest hit is Vulkan performance (~20% less than Windows iirc) but for desktop and casual gaming use, Nvidia's proprietary drivers are perfectly fine.

Another post suspects Nvidia drivers: https://davidjusto.com/articles/m2p-latency/#results

> I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.

If they are chasing a placebo effect, it's a really powerful one, since all the actual competitive people are often willing to sacrifice all detail and quite a lot of resolution to get those stupid high frame rates.

I can see the difference too, but the diminishing returns usually make it not worth it, since I prefer the eye candy better details and higher resolutions give me.

Also, some games can adjust the resolutions on the fly to keep a consistent frame rate. It's only become a feature on modern games, but I believe that's mostly a historical accident. PC games could often run on much worse hardware than they were actually designed for (with minimum requirements often being absolute minimums, and not 'this is what we developed for'), so people played them on low frame rates, so that kind of jank was often more culturally accepted on PC, and if you didn't want that experience, you could always upgrade. While on console, there was no upgrade path, and games were optimised for that one config, and thus never allowed to drop too far into the red (and dropping resolution is often a better option in those cases).

As someone who is in the rendering space for work. Having a higher framerate does help, but in a weird way. Basically the start of the frame rendering is what mostly dictates where objects are rendered. By getting a higher framerate the position of objects that you see in game are much closer to their "real" position. So it's less about seeing more frames at that point and more about seeing the most up to date information possible. Technically it could be possible to render the frame in sync with the framerate and just offset the rendering so it finishes right before it's pushed to the screen, but if you're slightly wrong you'll get really bad stuttering and the execution time of gpus and the cpu submitting the work isn't really deterministic.

Many PC games have dynamic resolution, too. The reason consoles target 60fps is because that’s the frame rate you get with most TVs and everyone playing the game has the same hardware (or couple variants).

> Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.

A newly rendered frame can cut-in during scan out. This shows up as tearing artifacts where the frame is changed while being sent to the display, but it allows fresher pixels to hit the screen below that tearing line. So each frame on the monitor can be a mix of multiple rendered frames.

It’s not as good as having variable refresh rate display with high refresh rate, but it does reduce latency.

For less action based games it’s common to turn vsync on and pace the frames to the refresh rate to eliminate this tearing.

   > If you set light mode, you'll get some light gray text on lighter gray background somewhere, but if you use dark mode, then you'll get some black text rendered on a black background elsewhere.

I've been using Linux (Linux Mint Cinammon, then Fedora Linux GNOME) for over five years and I've never had that. What kind of desktop environment, themes and applications are you using?

My experience has been reasonably consistent. My main DE is KDE, it switches between light and dark based on my location and time. It switches to warmer colors at night. I have never had a problem in the applications I use. I occasionally switch on the fancy effects like windows fall apart when I'm in the fun mode, or I'm showing something to friends, as a bit of fun makes everything more interesting, and all work perfectly well.

Sure, but isn't that the point? Needing to be a celebrity to fix something?

It's vibes when you don't have the tools to isolate and measure it. It's unfortunate that “vibe” is almost always pejorative these days.

Yes, rpm-ostree solves that

https://docs.bazzite.gg/Installing_and_Managing_Software/rpm...

https://coreos.github.io/rpm-ostree/

I use Bazzite for development bc it works like a Mac with sane defaults and a just works approach:

- IDEs are no problem. Editors will "just work" for anything you type into the app store - Bazzite handles the special cases for you and installs them through brew taps or Flatpaks.

- For development it's basically just like a Mac where you also can't install system-level packages: Node, Python etc work through brew / nvm / uv same as on Mac. Development that involves containers will be unchanged from a Mac. For compilers specifically, same as on Mac: Install it through brew, or if you need a Debian or Fedora base you do `distrobox create` and you can apt-install in a transparent podman container.

The immutable fs thing isn't just Bazzite; it's a fork of Fedora Silverblue[1] (it sounds like AI wrote this, but it didn't! I fear I am becoming the AI...)

Immutable filesystem-based operating systems became fairly widely used as the "base" system for Kubernetes nodes. Because on a container-focused system, you never need to touch the rootfs.

This started as a project called CoreOS[2], which was eventually acquired by Red Hat for its OpenShift (Red Hat Kubernetes) platform.

On servers, immutable rootfs makes a lot of sense. Silverblue (et. al.) was an attempt to see if that concept translated to Desktop systems well. Reviews are mixed. Some people swear it's the best thing since bread. Other people claim it's worse than having dental work done.

I'm personally somewhere in the middle. I think the concept is good, but if you want to do anything to change the core system, like installing custom video drivers, it quickly becomes a pain. I like to equate it to the "n00b"-OS. People who "just want the damn computer to work", immutable is great, because neither they nor an application can do anything to really break the system. On the other hand, it really limits (without complex work-arounds that other systems don't need) what "power users" can do.

In "the perfect immutable OS world", you would never directly install any application; instead, you run everything in a container (i.e., Flatpak). So you have layers of protection: an immutable root and a container-based permission system; the worst* thing an application could do is blow up your home directory. But if you manage permissions correctly, the most damaging thing would be an application blowing up only itself.

[1] https://fedoraproject.org/atomic-desktops/silverblue/

[2] https://www.redhat.com/en/technologies/cloud-computing/opens...

The immutable linux is pretty great if you find one that fits you type of dev work. The prebuilt images are powered by a config (so you could build your own) but it's great that you can just follow someones good "config". Switching/updates are suddenly easy.

For example i just need docker for webdev and there is bazzite-dx basically bazzite with docker and few things added. Works pretty great, sometimes when something goes bad i rollback the image and wait for future version.

It competes with steamos. There are other gaming distros that work like normal distros.

You can modify the fs using rpm-ostree. It will overlay your changes on top of the immutable image. The recommended way is to create toolbox/distrobox which uses containers to isolate stuff.

Yes of course, but you need to do it via the package manager. You can't "sudo make install". If you build your own software and want to install it system wide, you need to flatpack/brew it or run it in a docker container.

(obviously you can modify the filesystem if you really really really want to).

Bazzite is gaming oriented version of Fedora CoreOs. There are many different versions. I am running bluefin.

I've tried a lot of desktop linux distros, and to be honest, immutable linux feels like the future. Anything you do can simply be rolled back. Break something? Just roll it back.

And if you run something like Bazzite, but want to try out Bluefin-Dx which is developer oriented, then you can rebase your existing installation. If you don't like it, just revert back to Bazzite with a single command.

However, it's desktop oriented. Don't run CoreOs on a server.

In addition to the other comment mentioning rpm-ostree, brew is installed on bazzite by default and works about as well as it does on macOS.

You can also use fedora toolboxes to create containers mounted on your home folder, though it is clunky.

Because if it's open source you can't make money from it or have multiple tiers.

Bazzite mostly suggests installing stuff via Flatpak or Homebrew. (No, really, brew on Linux lol). You can also layer in things with rpm-ostree but it's clunky. I think the immutable OS makes sense for a consumer but not for a developer.

So I'm using Nobara instead. It's a different Fedora-for-gaming but has most of the same improvements. It is a traditional system, not immutable. CachyOS is also very popular and that gets you an Arch-for-gaming. Just yesterday I learned of PikaOS, a Debian-for-gaming.

The main thing all these gaming-customized systems are doing is getting graphics drivers and proprietary codecs installed for you easily.

Afaik reflex is a bit different - it times the input to frame latency in your game, and tries to start the gameloop as late as possible in the frame so that your input gets sampled at the latest possible time and the frame still makes it to the vsync period, this isn't really a compositor tech.

Oh sure, but if I just need to troubleshoot why Minecraft-launcher (a first party app) won't launch ... it didn't give any output; it didn't even exist apparently, but only because MS were hiding it, had to crack out Process Explorer just to get something to troubleshoot on ... then it turns out the "turnkey" app from their first-party app store, loading the first-party app, on the same company's OS just failed with no indications to the user at all, not even a "this app crashed". Solution was to cut out as much of MS as possible ... it's just infuriating when it doesn't work, which seems to be all-the-time.

More power to Bazzite and Valve, the sooner games app run in other OS the better.

What you're saying doesn't make any sense. Gamescope is essentially a XWayland-only compositor (with some basic xdg-shell support that's disabled by default). All games on SteamOS go through XWayland.

It doesn't yet mean that it suffers from the latency measured in the article, as the problem could very well be in something else, such as how KWin integrates with XWayland or how GPU drivers interact with it (especially that Nvidia drivers have a history of making XWayland suffer).

gamescope absolutely can have Xwayland child panes & this is currently the default on SteamOS running games with Proton, unless PROTON_ENABLE_WAYLAND=1 is set in the game options.

Different order of magnitude in my experience.

Wayland mouse movement lag is/can be/could/was in the order of several hundred milliseconds.

Its that that people notice, not 3 or 4ms difference in click response.

Yes, I am determined to shield my servers from malicious actors and bots that attempt to exploit it. This sometimes can lead to false positives and I am willing and cooperative in rectifying this to allow open access to real people that want to access the services I provide and make sure stuff like this won't happen again.

The security and availability of my servers is as important to me as the ability for anyone to access the public services I provide. Which is why I responded to you immediately and asked for your cooperation to help me fix the problem.

You not being cooperative helps no one. Not yourself, not other people with the same issue and not me who's trying to fix it.

Crowdsec is free btw, I do not pay anything.

This is actually a laptop with its builtin display.

Edit to add: I don't think it has too much to do with display latency.

It is some convolution of the desktop environment and display server deciding that keyboard input doesn't go to the focused window while it is in this nominal screen blank state. This Fedora 43 on a boring generic Thinkpad.

I've set up sunshine + moonlight on Fedora KDE Wayland, and I've played remotely from a different country with unnoticeable input lag (using a gamepad, playing Cyberpunk). The whole thing is even behind WireGuard.

I have very fast internet on both sides, both fiber to the home, with only the tablet running moonlight being on WiFi.

That's the price of Enterprise/Business plan. He might be using the free community version.

I have no idea about gaming but in the music world you start noticing latency when it is above 5ms and the difference between 5 and 8ms is tangible. For the most part anything under 10ms is workable and you will quickly adapt as long as the latency is constant. Under 10ms of latency is a level of latency we are used to dealing with, if you are playing guitar and your amp is 10 feet from you, you have ~9ms of latency. Our brains are pretty good at adapting to these short latencies as long as they are predictable.

The visual latency on gaming could be different but I suspect not, I think it is more an issue that some people fixate on the latency, others just accept and adapt to it. Games do have more possible sources of latency, visual, audio and io, and if these can all be different that can be difficult; years ago I had an issue with this and midi, that one really threw me off. Games may also not model the physics of sound? does sound travel slower than light in games? That could worsen the problem since sound does travel slower in real life and we are used to that, we expect it.

It's very valuable data that everything is so close. It means that most folks can simply ignore it. On the other hand the inferior nature of xwayland well explains the bad rep for wayland latency.

Consider also that people neither run the latest thing nor the fastest software and remember potholes long after they are filled. EG it wasn't that long ago that wine was running on xwayland almost exclusively for instance and the majority of popular titles run via wine.

Spartan...haha...I mean it's all relative. Certain relative to the other two boxes I use daily - macos & win.

I do know it is favoured by ricers with animations & transparency but I just use it to tile stuff. Think I selected it over sway & i3 due to wayland support at the time. Not sure.

The context here is the article's author is a twitchy FPS player, those extra 3ms are something that community agonizes over. I appreciated how much effort was put into controlling the variables in this test. There's a whole lot of witchcraft associated with these kinds of efforts and he sat down and did the measurements and got real numbers. My hat is off to OP.

When you say game streaming, is this the steam streaming stack?

That's what I mean though.

I've not used gnome for years, but I have a vague memory of gnome/mutter running on a single main thread which used to lock up quite a lot (javascript etc). And because in X it was X that used to manage things like rendering the mouse pointer every frame, whereas in Wayland it flipped to mutter having to do it directly, the stalls were way more obvious in wayland than X, which is where I think a lot of this perception came from.

Again, not sure how much of this is accurate, but that's the point I was trying to make.

I can tell down to about a 3ms difference in lag. Actually even down to 1ms, it's not all its cracked up to be, lemme tell you.

try to share your screen on a native tool older than a few years lol

No. Wayland has been in development for 17 years. People have been claiming its been ready for prime time when it wasn't for a surprising portion of that time while it had substantial deficiencies while the boring old shit continued to work fine.

It has been ready for users whose sole usage is an editor a terminal and a browser on their single screen intel laptop as long as they didn't also open youtube since 2015.

Imagine the boss's nephew joins the firm. He knows less than nothing and is worse than useless everything he touches turns to shit. People understandably complain. After 10 years of development and other people's time he is now moderately capable at his job. People still bitch. They aren't lying or wrong. They just aren't current.

And FWIW, KDE probably make the most effort with their compositor. They have historically been well ahead of the curve for things that might affect this (e.g. VRR).

Tearing can theoretically improve latency for the part of the screen that's below the tear, but in any case where you could actually benefit from it the difference would be at least order of magnitude smaller than the duration of one frame.

To put it in perspective: an average eye blink is 100-150 ms. The worst outcome in this test was with XWayland adding 3ms of latency. Maybe this is truly important for some exceptional pro gamers but for the majority of the world it is as you say, stupid and pointless.

It's really not like Emacs/vim. I use X because it works on my setup and always has, whereas Wayland has not, despite Wayland advocates claiming it's ready and X is deprecated for 10+ years.

You will also get different results by gpu, compiler, kernel, architecture, and then of course compositor. Even a slightly different version of some lib might throw off the results.

In any case the methodology in the post is sound and should be used for benchmarking in the future.

You might be right, 8 ms of total end to end latency is about 1 frame at 120 hz or half a frame of 60 hz, someone would need to be quite competitive to notice that. And the baseline was 4 ms, so going from half a frame of total e2e latency at 120 hz to 1 frame, not much of a difference. Also in 2026 I'm realizing it might be doubtful that many games would still be only x11, so I'm not sure how common it would be to encounter xwayland in a game today realistically.

I think the author’s use of a 500Hz display covers up or minimizes a lot of issues. It’s really easy to look at this data and say 8ms click to flash is fabulous even though he has an config that does 4ms.

A better way to interpret this data is to normalize by the vsync interval or the swap chain depth. The slowest config is 2 frames slower than the fastest. At 500Hz this is 4ms extra which is likely imperceptible to everyone but elite pro gamers. At 60Hz this is 34ms extra which is pretty noticeable to even casual gamers.

I mean normally this type of discussion is silly, but in playing competitive shooters latency does make a huge difference, and it shows that XWayland is adding ~4ms of latency.

There is a native Wayland driver for Wine/Proton but it's enabled through an environment variable, not by default. This will probably be default in Wine 12/Proton 12 because Valve wants to squeeze as much performance out of SteamOS as possible. The gaming mode UI runs under Valve's own Wayland compositor (gamescope) already, but games are currently in nested XWayland windows.

well according to post, coz they are very similar. but xwayland doubles it

which is still half a frame at best so I think any blame here would be just on a particular game being slow on inputs

Why would it need to measure input to frame latency? Surely it just needs to measure how long it takes the game to go from vsync period to frame ready and delay when the game thinks vsync happened to force it to poll later in the cycle?

The developers of Process Explorer have a lot more to do with the OS than the makers of Minecraft, even if the company name is the same on all three

Oh yes, that makes a lot of sense.

Is this some kind of Pavlov's dog reaction? That's not what my comment was about, and even if it was it wouldn't make any sense anyway as KWin had good results in these measurements.

Sure Wayland works fine. What you're not seeing is the hours and hours of volunteer labor wasted to get it to that point. Time that could have been spent working on features users actually cared about, now wasted "adding wayland support" to your favorite applications. If you could quantify it, the waste would be borderline criminal:

- Effort spent writing sway that could have been spent improving i3

- Effort spent writing GNOME-Wayland that could have been spent improving GNOME

- Effort spent writing KDE-Wayland that could have been spent improving KDE (much of this work duplicated effort with GNOME-Wayland)

- Effort spent writing wlroots to try and mitigate the effort being wasted by people writing bespoke compositors

- Wine/Proton devs needing to waste time getting every windows application to work in Wayland

- Firefox needing to target both Wayland and X

- A bunch of graphical toolkits and window managers that were working perfectly fine but will now be "left behind" since they lack the maintainers to support a porting effort

- low-level toolkits like SDL needing to implement their own window decorations now that they're not guaranteed to be provided by the OS (what?!)

What Wayland proves to me is just how easy it is for a small number of developers to unintentionally sabotage productivity in a much larger project.

This is the complete opposite of those discussions. It's taking a specific quantifiable thing and measuring it, with enough information for anyone to try and reproduce the results.

It's the epitome of science, comparing it to a generic vim vs emacs flamewar which is pure subjective opinion is pretty baseless.

My biggest problem with wayland was how it was basically forced on the community. It broke innumerable things for years, put all the responsibility for implementing things down on the DEs and WMs themselves.

All of this hassle, forcing so much more work on DE/WM devs, for the sake of 'better security' in scenarios that don't really apply to 99% of linux users, with the promise of 'better latency' which this very article proves is false.

I tried to be an early adopter of wayland ~ 5 years ago. Found all sorts of things broken, and I'm now using linux mint xfce edition, as hopefully by the time xfce drags itself to wayland, all the bugs and tooling will be a solved problem.

I don't think there was ever a design to be one frame behind.

Compositing requires the GPU to do some extra work to draw the frame to be presented. This typically takes very little time (much less than a full frame period). Additionally, most wayland compositors will bypass that extra step if an application is full screen (wlroots calls it "direct scanout").

Also some wayland compositors keep track of timing and delay the final composition until right before it is time to present the frame in order to reduce latency.

Yeah at 120hz each frame is 8ms. So you're only missing a single frame around 30% of the time.

I certainly want my latency as low as I can get it. But I'm pretty skeptical that anyone is truly feeling the difference of a couple ms.

If it's open source you can make money by selling managed services to companies. They don't want to deal with it really.

Why not for developers? You can install tools from flatpak or in home directory. My workflow includes toolbox containers. Distrobox is also good option.

There’s an argument to be made that dropping all unimportant detail could make professional players react faster even if it doesn’t improve end-to-end latency in the PC.

This is something that could be tested experimentally, but isn’t, because the subjects we would need to test this on are all sponsored by hardware vendors.

Seconding this. I'm not happy with the fact that the drivers are proprietary, I really prefer FOSS. But, I am tired of having to deal with FUD around performance and issues with NVIDIA devices which simply don't exist at scale.

I have friends who are stuck on Windows not because they play games with Windows-only anticheat, but because theyve been told by GNU heads that NVIDIA drivers simply don't perform acceptably on Linux.

As the frame rate goes up the lag between the game state and display state goes down. It doesn't matter that the "extra" frames aren't displayed, the frame that is being displayed needs to be as up to date as possible.

Consoles target 30fps though. Very rarely they target 60fps and even less rarely they can reach that.

Yeah, I believe Mutter is directly responsible for a lot of bad rep Wayland gets. It got better in many areas, but the damage is done.

sunshine + moonlight is the streaming stack. Steam's one is pretty bad, and still only works in X11.

You think you can and will inevitably fail to do it in blind testing.

ping is going to dominate over 3ms in pretty much every situation.

And the non-xwayland numbers are all within a single ms of each other.

---

Not to undermine the measurements of the author (agree with you, it's a cool effort), but my read is that this was basically proof that it doesn't matter.

How incredibly arrogant of you. Its their time to spend as they see fit. You get no say in that and complaining they didn't do what YOU wanted them to when YOU wanted them to do it is peak entitlement. Grow up

It's their time, not for you to decide how to spend it

The 'small number of developers' who no longer wish to maintain X and have moved on shouldn't be blamed.

Firefox is software rendered on linux-nvidia which leads to a bizarre situation of simple web animations lagging on decent computers.

Yes, thanks for saying it more concisely/clearly than I did. Just cause I understand something doesn't mean I'm good at explaining it.

Many flatpaks aren't actually maintained by the actual developer nor the normal way the package is normally used. You may have bugs that aren't present in the package that the dev isn't aware of or interested in fixing especially if they support a different channel and the bug relates to sandboxing.

There is also a risk that the person may be malicious from the start, sell out, or simply get malware. Given the nature of the ecosystem a malicious release to a previously safe package could propagate incredibly quickly.

Where there are multiple steps for a package to get from developers machine to yours and each is slow enough for malicious behavior to be noticed each step adds friction and decreases the chance of ultimate success. Where all steps are nearly simultaneous your risk multiplies with each step in which a different person has their hands in it and if any of them are malicious or compromised you are screwed.

How is Red Hat's revenue compared to Microsoft's?

You can genuinely feel just a few milliseconds of input latency with a mouse, it disconnects looking around with your physical actions. It's the same way you can feel the difference between low and high refresh rate monitors, even though you can't really count the frames themselves

> I tried to be an early adopter of wayland ~ 5 years ago. Found all sorts of things broken

Yeah, because it wasn't ready. Pretty much no one recommended using it back them, if you thought it was ready you were either misguided or misled. It's time to put your skepticism aside and give it another try, there is a pretty good chance it's going to work great now.

Even Valve Steam OS is now adopting it. It's a pretty good sign wayland is a viable replacement for X11, while bringing it own things.

Forced on who, by who? It is the DE/WM people that is driving the thing.

And for the complete picture, X is predominantly used with a compositor, so that same extra latency exists there as well.

Try musicians that are used to playing extremely high speed semihemidemisemiquavers.

We notice latency. Neil Peart could almost get sample-precise timing, he was so godlike.

It's exactly what your comment was about: the same boring motte and bailey fallacy of “you don't understand, wayland is a protocol”

If your protocol you pushed to replace a working implementation invites a dozen poor implementations which people routinely confuse, that's a problem with the protocol and the push to get people to use it.

And all the gaslighting. Using X forward basically every day but being told it is useless and broken and nobody needs it...

I don't know enough about this to have a favorite, just know the transition was rough. Like one day at work our DE had to get changed because of whatever reasons they couldn't use X anymore, and that affected more things like Chrome Remote Desktop. Years after I tried setting up Linux on an old PC and learned that Wayland is de facto default now, but not in Mint, even though Mint is supposed to be the easy one... and CRD was still finicky in either one.

Linux is about choice, but unless you're ready to write a lot of things yourself, it's outside your control how well parts of the ecosystem are supported. For an average user it's unacceptable for your entire GUI to suddenly change in a way that requires relearning, something that Mac and Windows have avoided doing at least since 2000. Even Win8 or Mac26 wasn't so disruptive. It's possibly worse for an average Linux user because they aren't just concerned with how it looks but also compatibility with advanced things like X forwarding or VNC or CRD.

You can measure a 3.3ms difference, but whether someone will notice and care is a different thing.

And the attitude of just refusing to make things work because haha fuck you that's why. I think it was Kicad or Gimp or Blender where you can drag windows onto other windows to merge them and they had to add a warning saying this will never work on Wayland because Wayland doesn't want it to work.

A fair argument at least for some games.

The games I have in mind though still have those details present on lower settings. Instead they just look like shit rather than disappear. To be fair though, that just might make those details have higher contrast and not fade into the background as much.

That's outdated information. Most PS5 and the equivalent Xbox games target 60 fps nowadays. It's usually huge news when a game is only 30 fps.

I'd say it's deserved, not FUD. Nvidia did improve in some ways, but it's still way too heavy into blob even in case you plan to use it in the future with nvk. Nouveau / nova developers explained that Nvidia pushed a lot more into their firmware than AMD, turning the kernel driver into more of a shim than an actual driver. That's already a big downside.

mostly i'm trying to get out of the terminal and most IDEs don't understand devbox/distrobox well without lots of finagling.

In the context of competitive online games, ping is going to be ~10-60ms, depending on your connection to the particular server you're playing on, and not particularly noisy (and that's a roundtrip time. Client-Server latency would be 5-30ms). In order for one value to "dominate over" another in an adversarial context, the variance of the former must be much greater than the base rate of the latter.

Imagine a game that's just a pistol duel. When the kerchief hits the ground, players press a button, first person to press the button wins.

In an ideal world, with no delay whatsover, the probability P(A) of player A shooting no later than player B is 100 (because both players shoot at exactly the same time). If we add 5 ms of delay to player A, then P(A) = 0 (he will always lose). If then we add 50 ms of network latency to both players, P(A) = 0 still, because 55 > 50. If we instead make that 50ms delay 50ms +- 10ms (ignoring normal distribution for the moment, pretending every value in that range is equally likely), there's a 25% chance of player A experiencing an unwinnable delay (any network delay value > 55ms results in a value greater than player B's max of 60ms), resulting in a probability of P(A) = 75% * 50* = 38%.

If we make the network delay 50ms +- 5ms, then P(A) drops to 25%.

It doesn't matter. Whether you have a ping of 40 or a ping of 300, 3ms is 3ms and will mean you win a little less often.

The saying we have in bike racing marginal gains is "leave no stone unturned, but turn over the big ones first"

So sure, first make sure your internet connection is solid. Then make sure your hardware and game settings are optimizing FPS to a reasonable point of diminishing returns.

Then make sure you don't use XWayland

Humans are good at predicting stuff, and they can notice when the expected doesn't happen.

But I wouldn't necessarily say that people can notice it everywhere in every state of mind. The medium, context etc all matter a lot.

There is a wayland equivalent. It's called waypipe. In my experiences it often works better than x11 forwarding.

And don't forget the “this isn't a wayland problem” whenever a major missing feature provided by the X11 ecosystem is mentioned. Guess what: if you're going to replace the whole ecosystem, you're responsible for all the missing things regardless of your opinions of the matter.

Looks like this pavlovian reaction is quite widespread. It's baffling how can you so confidently miss the point.

Yeah I used x forwarding to access matlab from my uni lab from the comfort of my own home, while all the other students had to slog to the lab lol

It is absolutely not the DE/WM devs driving this, it's the wayland folks saying that xorg would no longer be maintained. They literally just dumped an Ikea box of protocols on the table without even bothering to provide a decent sample implementation and said 'good luck!'

People were declaring it ready in 2016 10 years ago and talking about how people needed to switch off the working "obsolete" X and switch ASAP to the broken wayland.

It is completely counterfactual that "pretty much no one" was recommending it in 2021

It's generally a single checkbox to turn off compositing in X11, for precisely this reason.

I think Linux is about choice some folks opinions notwithstanding. It's an ecosystem where many different devs have chosen to go about the same thing many different ways. You the user then get to pick from amongst those varied and interesting choices.

It however isn't about all or indeed any of those devs being obligated to support any particular choice. You can only buy a place at the table with money or sweat and merely using something isn't contributing and doesn't get you a vote.

Arguably the problem isn't the display server its the fact that general linux usage tends to require a little understanding of what's going on under the hood than is strictly speaking desirable for joe average user especially when something doesn't work. EG needing to understand that your choice of display server is making your zoom calls not work and then having to open that whole can of worms.

The fix is honestly more labor. The trivial way to acquire more labor is with money which is hampered by the fact that so little is paid. If you want more polished stuff pay more.

That's outdated information. Most PS5 and the equivalent Xbox games target 30-40 fps nowadays. With an additional performance mode that targets 60 fps, but with lower quality

Why Nix is great; you can run the IDE from within a Nix-managed dev environment and not have to teach the IDE about it. You can point a .desktop shortcut at it too.

Requires a different way of working with projects though, so understandable if that's not your thing.

I install the IDE as well as tools inside distrobox.

You can feel it, too. In particular when you’re used to smoother.

It’s like going from 240Hz back to 60Hz, or even 240Hz to 120. People can tell.

It's a tradeoff, and if you're not doing any fancy-pants CUDA work then it's a pretty big one. But most people are already using these blob-heavy drivers on Windows, so switching that same system to Linux is not a huge downgrade in terms of usability or stability. It isn't recommended for new Linux PCs, but it's not a dealbreaker for people switching OSes (anymore).

By the time wayland becomes the default in xfce, maybe the wayland team will have added window positioning to the protocol...

Well, new GTA is 30 fps only. Some (most?) games have performance vs quality toggle. Quality mode being 30 fps, and performance mode looks too ugly.

Sure "only 30 fps" is big news, but pretty sure "quality mode target 30 fps" is still norm.

In Xbox, many games launched at 30 fps only, then gained 60 fps mode.

Until I see majority target at least 60 fps as minimal mode, my point IMO stands.

Yeah. I think there are so many hypotheses we could test if professional players were willing to do these experiments.

For example, it used to be popular among competitive CS players to use 4:3 resolutions on 16:9 monitors. Since the target’s vertical position is much more predictable than its horizontal position, it’s supposedly easier to aim if the image is stretched wide.

But these games only presented 4:3 options at low resolutions. This might have introduced the notion that low resolutions provide an advantage in general.

You can also disable compositing conditionally in KDE, such as when a game window is opened.

>Arguably the problem isn't the display server

No. If you tell users they should switch to a new display server, you shouldn't be surprised if no one takes you up on it if you don't provide basic feature parity.

If you tell DE/WM devs they should use your new protocol, but say it's now their responsibility to do all these things that the old display server did for them, don't be surprised if it doesn't get much traction.

I don't for the life of me understand why wayland took off. It's provided no benefit to the average user, or DE/WM dev, and a whole lot of hassle.

Let's ignore this point of the discussion. For how long do you think users stayed on wayland back in 2016? The vast majority of users experience was... nothing because it wasn't even being shipped by 99% of distros yet, and if they cared to sought it they used it for 5 minutes until it crashed or even 0 minutes because it couldn't even display anything on their graphics card. Very few people actually experienced and tried to use wayland for real back then. Most of them were either devs or enthusiasts.

Fast forward to 2021 and most users experience with wayland was that GDM (on some distros) would try to start on wayland mode but couldn't for some reason and would fallback to X11. Note: I do think that the distros that were pushing for this were being reckless with their users. Introducing it as an opt-in would be much better and would still lower the barrier for testing. Also, KDE didn't even offer a wayland mode, taking until 2024 for it to start defaulting to it and any other wayland desktop had to be sought after by the user.

So really, I think people only started to "suffer" wayland's wonky-ness for the last three to five years depending how you view it. And honestly the last year or two has been pretty usable.

It's become less common to play in 4:3 over the years. The additional peripheral vision has become too obvious a benefit to not make use of.

It's probably mostly a habit thing. Most of the pros started to play these games back in the 90s, when 4:3 was the standard. Add in that playing all the low resolution options are 4:3 (and the 16:9 equivalents will add resolutions rather than take it away; the 1080p is usually 16:9, so 1920x1080, but 4:3 1080p does exist, and it's 1440x1080, which is a lower resolution), it's no wonder 4:3 stuck around as long as it did.

Depends on the game. Many shooters have always targeted 60 fps (COD / BF iirc). A single player game may well target 4k30hz unless the user selects 'performance mode'.

In the PC version Resident Evil 5, hit reg with a particular boss is tied to fps, so I had to lock it to 30. Going from 165hz to 30hz was noticeable, everything above 60 just felt a bit smoother to me but 30-60 was night and day. I rarely notice it when playing on console.

Ironically the only game where I've ever felt I had to enable performance mode was Life is Strange. Not the sort of game you'd think would suffer from 30hz!

Not in Wayland, the whole point of Wayland is to make stuff the X server + compositor + various other bits into the window manager.

I had to turn on performance mode for some fights in Expedition 33.

> Depends on the game. Many shooters have always targeted 60 fps (COD / BF iirc)

Define always. I don't know about COD, last COD I played on console was targeted 30 fps on PS3 and the same was true for every PS3 shooter. BF5 ran at 50fps on average. Battlefield is really an exception to the rule because they lowered graphics waaaay lower than on PC to get reach 60 fps. IIRC ps5 Pro can reach whole 120 Hz in BF6.

PC ports of Capcom games are always piss poor so no surprise there.

Biggest FPS surprise FPS for me was Destiny 2 where PvP damage to you was tied to your FPS.