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

One thing that's lovely about Linux is this kind of analysis is not only possible, but meaningful. 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.

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.

Awesome article.

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.

He seems confused at the end why people think wayland is so slow, but don't you think it's because of his xwayland result? People were probably running x11 games on wayland and noticed that significant lag. Just a wild guess. Very nice article, wish people did actual measurements like this more often, of all sorts of things.

There's no such thing as "Wayland input latency". It's just a word salad, akin to "HTTP animation smoothness". The post is measuring Xorg vs. KWin (and also XWayland), other implementations of either X11 or Wayland will have different characteristics.

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

Been dealing with this a bit at Breaka Club. We teach kids to code with a modded version of Overcooked 2!.

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.

I am not super familiar with Wayland, but basically how composited rendering under X11 works, is if you have a fullscreen window, you can give an 'unredirect' hint to the compositor, in which case when nothing else is drawing your screen, it will stop compositing, and pass your app's swapchain directly to the screen.

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.

Very interesting!

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.

It looks like consoles and PCs have settled on somewhat different gaming configurations. Consoles usually try to target a fixed output frame rate, while the resolution is often dynamic. On PCs, by contrast, the resolution stays static, while the frame rate and frame-time pacing are dynamic. How does this fit into the latency discussion?

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 used a 500Hz display which hides a lot of the problems that would show up on slower displays.

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.

Really hope to see a Windows result. What if Windows has a latency of 10 ms+. xD

How does Windows compare to this?

I wonder though, updated pixels might not have the same latency on the whole screen, and it might even be affected by some updates mechanisms, like panel replay. I.e. it would have been interesting to also measure the screen position as a dimension.

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.

Yes, we know wayland is not only slower but also with much less features.

Using Wayland (hyprland) for daily driver and it's the happiest I've been with an OS in a long time on feel. Feels crisp in that spartan way that windows & macos just don't - no animations, taskbar, popups or god knows what else.

The Rock Band guitars have a photoresistor for precisely this purpose: the screen flashes and the guitar responds when the light hits it. It helps make the otherwise very painful calibration process transparent.

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...

SteamOS and Bazzite both use Xwayland through gamescope which is the worst option as it seems https://github.com/ValveSoftware/gamescope

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

A lot of people conflate Wayland being worse than X11 with Gnome on Wayland being worse than Gnome on X11.

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

I have a vague memory of (X?)Wayland being much worse than X11 before, and some patch or protocol making it out to all the relevant implementations, but I might have imagined that, since these result show virtually no difference, and only XWayland shows a marginal difference.

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

Great article! Thank you. Also in case others walked away with the same question I had, I'll save you the googling: use the utility vrrtest to help validate if VRR is properly configured on your machine.

Wow, love this!! This is what makes HN great!

This is awesome. I would like to see tests like this done at 60 Hz as well, and also with non-3D apps. I suspect the results might look different in those conditions. A 500 Hz monitor is not the common case. 2ms is a whole frame!

Linux is underrated and is only getting better. I am building a linux cloud platform so we can build unity and Godot games with mcps right in your browser. Not only is Linux the only option but I have realized it is the best option for AI

I saw a very similar post a month or two ago, is this the same author?

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

Very interesting analysis and setup.

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

Why isn't Wayland better than X11?

Amazing work. Thank you for putting this together.

This is why I read Hacker News. Thank you.

> A lot of people still use X11 over Wayland because Wayland is said to have much worse input lag

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

I'd avoid Nvidia to begin with.

From the "Similar Efforts" section toward the bottom:

---

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.

X11 is a protocol. Xorg is an end of life'd project run by the Wayland team.

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

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