Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

I recently switched to Linux after years on Windows desktop, mostly because the KDE Plasma desktop feels snappier than Windows 11. Also the feeling that if something isn't working right I can probably tinker and improve it. It's been really nice. If you haven't tried Linux desktops in awhile give Bazzite a whirl: it's a Fedora customized for gaming. Even if you don't game it's an easy way to get a very functional Linux desktop in no time at all.

I switched my daily driver / gaming rig to Fedora a few months back.

Everything seems snappier compared to Windows, but not sure if it’s in my head, and I’ve been very curious about gaming input latency. This helps answer some questions.

I recently switched to hyprland and I’m very interested how that fits in these results. hyprland uses Wayland so I hope the author might revisit now that hyprland is gaining in popularity.

I’ve considered using gamescope to hopefully get in front of some of these concerns, but I’m on nvidia and there is some discussion about it not working well there.

Now the author's got me thinking about gaming-optimized kernels, which I did not realize was a thing.

I play competitive fighting games so input latency is a huge concern. Would love to hear from anyone else who’s been down this path.

The XWayland result is 3ms slower, which at refresh rates this high makes me wonder if it was one frame behind.

Running the tests at 120Hz or even 60Hz might be more interesting because we could start to separate out very small differences in timing from the much larger effects of being a full frame behind.

Of course, where gathering this sort of data _is_ useful is diagnosing and fixing real latency so it obviously has merit. I just think it's ok to lean on taste and experience for most things UI/UX, including latency.

Another point, by couching the comparison in a less technical form (for example, rating a configuration/setup out of 5 stars or some similar approach), it protects from being "too methodological" during testing and data-gathering. One possible issue with the author's methods is if there are degenerative cases that are common in the day-to-day experience of a given configuration, they are unlikely to be present during the precise test that they have setup.

I wonder where the XWayland's added latency comes from though, it seems suspiciously high to just be easily hand-waved as overhead.

My system flashed the screen white and played a note. The idea was to have the camera detect monitor brightness and detect the offset from the audio note. I'm practice the brightness of a 40 inch TV didn't seem to impact the video of the insta 360 link webcam.

(I ended up vibe coding a Python GUI to quickly allow me to push through video frames and show the audio frequency. I could quickly type 'v' (video) where I clapped and 'a' (audio) where the waveform changed. It would then tell me the offset...

We stream OC2[1] with our mod preinstalled over WebRTC. This ensures that kids/schools don't have to try and install the mod. This is particularly important since we support running on school provided hardware. Installing a game without a mod would be hard enough. Added advantage though is kids play with a virtual (on screen) gamepad on iPads in Mobile Safari.

Game instances run in Docker containers in Kubernetes/k3s atop very outdated nVidia hardware. Given we're already going across the Internet into school networks, we've tried very hard to optimize latency across the board. Using NVidia NVEnc with DMABuf (zero copy) etc. We're unfortunately using XWayland at present so experience the documented input overhead. Although our inputs are virtual devices at this point, so the overhead may be a bit different. Trying to optimize this whole thing end to end has been a challenge. I would say that performance is currently "acceptable".

OC2 coding: https://www.youtube.com/watch?v=ITWSL5lTLig (not streamed in this case)

[1] We've bought a limited number of copies of OC2 and pods claim a license on startup. If we're at capacity, kids play something else.

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.

Am I out of touch, or is it the children with colored LEDs on their DRAM sticks who are wrong?

This is pretty much optimal, and you can't really do much better than this.

Once a stray window appears on top, or something makes the compositor think it can't do this, it'll do the intermediate step of compositing your app window with others into a temp buffer, and render that.

Sometimes the unredirect breaks for some reason (I remember a case where for some inexplicable reason my app kept creating a window 1px smaller than the screen height), or you use XWayland, you get bad latency.

Since this is a fundamental constraint, other compositors on different OSes must work like this, and you can run into issues like this as well.

Another thing - Wayland afaik started exporing 'display planes' - which are a HW feature of GPUs, that allow it to composite multiple layers together - which means the game can render at full FPS and all the windows on top will be drawn into a different plane and get composited with no ill effects - not sure if this is actually used in production yet.

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

https://www.youtube.com/watch?v=fE-P_7-YiVM

https://news.ycombinator.com/item?id=42832155

https://danluu.com/input-lag/

Even if everything else is perfect, display latency on modern panels is 1-3 ms. So all of the input processing and display pipeline can't be taking more than a millisecond or two and that's remarkable.

I also don't like to play above 60Hz.

It would be so cool to get that to work in Linux. I know the instrument code is in hid-sony. Here are some open tabs I've got in case anyone's curious:

- https://pascal.giard.info/techreports/nguyen-daniel-autocali...

- https://www.niangames.com/articles/reverse-engineering-rockb...

- https://github.com/torvalds/linux/blob/master/drivers/hid/hi...

E.g. I have an old laptop running a browser playing some internet radio stream. Eventually the screen blanker (without locking) activates.

Some real life event makes me want to hit the space bar to pause music. But the modern screen blank has decided that it should eat/ignore key presses while blank. So hitting the key doesn't pause music. I have to wait for the screen to light up before it will be possible to trigger the pause, and this delay feels interminable!

I seem to recall that in the old days the input remained active to the focused window even if the screen was in a power saving state. This power saving was not conflated with screen-lock security etc. I much prefer that. I think this was because DPMS power saving was an underlying X server behavior, not delegated to a screensaver/lock application?

I'd also be partially satisfied with the async behavior of old terminal programs. My inputs should be buffered and processed even if the effects haven't returned to the screen yet. Then I could at least hit keys twice and be trained to know that one would unblank, the other would pause, and all would be well (eventually).

The current behavior is like having a temporarily numb hand, and being frustrated waiting for sensation to return before I can operate anything!

Latency numbers are written with three significant digits (4.21 ms). I'm curious about the accuracy of the measurement device. If it can measure tens of microseconds, I'm impressed. If it can't, the conclusions in this article should be taken more coarsely.

>Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.

Or maybe it just came out of nowhere and was never true.

Also, both the input latency (usb controller, and its driver), and screen latency (input latency + processing + update delay) are supposedly also affecting all measurements, but hopefully somewhat consistent or at least filtered out.

Wayland has been great for me for a few years now. I don't use Gnome or nvidia though.

edit: no, this is the one I was remembering: https://farnoy.dev/posts/linux-latency

Wayland is fine. People should use AMD and KDE Plasma.

I'd avoid Nvidia to begin with.

Xlibre is an actively developed and maintained X11 protocol display server.

Xfree86 is dead, long live Xorg. Xorg is dead, long live Xlibre!

I wonder what is considered "unnecessary programs" by the author. Is "apparmor" or sandboxing considered in this? Or just user space applications (browser, discord, …).

I wonder if input latency would be improved if you ran setup as `root`. I wouldn’t do it for security sake, but just curious

---

David Ramiro built his m2p-latency and compared X11 vs Wayland in his article Building an Input Latency Meter (Because ‘Wayland Feels Off’ Isn’t a Metric) as well, coming to similar conclusions:

Native Wayland is on par with native X11 (all tied at ~7 ms), while XWayland roughly doubled the latency in his tests.

farnoy did extensive testing with the Open-Source-LDAT in his post Linux latency measurements and compositor tuning, also concluding that XWayland should be avoided.

[1] Github: https://github.com/DelusionalLogic/Frametime, Blogpost: https://www.jnsn.dev/posts/frametime/, and followup: https://www.jnsn.dev/posts/fastisslow/