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.
show comments
coldblues
Addressing all the people here talking about latency of under 10ms, I direct you towards these:
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.
show comments
cgyvbunji
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.
show comments
Aurornis
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.
seba_dos1
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.
show comments
Benjamin_Dobell
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".
[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.
torginus
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.
hs86
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?
show comments
sellmesoap
I appreciate the article, it's cool to see such small differences across all those settings! It says they learned to solder, if you see solder joins that look like those in the first picture, keep learning! Those are some dry joins, which can easily lead to failure, or intermittant signal loss. Soldering can be a touchy sport!
saltcured
The input latency that has been driving me crazy lately is the screen unblank latency to allow input to a program.
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!
show comments
bsimpson
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:
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.
show comments
criddell
These results are way better than what Dan Luu measured almost a decade ago:
Really hope to see a Windows result. What if Windows has a latency of 10 ms+. xD
stusmall
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.
>Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.
show comments
Havoc
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.
show comments
Telaneo
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.
feverzsj
Yes, we know wayland is not only slower but also with much less features.
gfxfan
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.
boomskats
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.
show comments
inigyou
This website uses IP address blocking to censor itself, and deserves to be publicly shamed for it. Here's an archive link: https://archive.is/hrYZ6
show comments
modeless
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!
PcChip
I saw a very similar post a month or two ago, is this the same author?
The main issue is with mouse movement rather than clicks tho...
show comments
clodecloud
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
dosisking
I wonder how FreeBSD X11 compares to Linux X11
ElijahLynn
Wow, love this!! This is what makes HN great!
closeneough
How does Windows compare to this?
dreamlayers
Why isn't Wayland better than X11?
show comments
hparadiz
Amazing work. Thank you for putting this together.
overtone1000
This is why I read Hacker News. Thank you.
shmerl
> 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.
show comments
xyst
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
esseph
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.
calvinmorrison
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!
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.
Addressing all the people here talking about latency of under 10ms, I direct you towards these:
https://www.youtube.com/watch?v=vOvQCPLkPt4
https://www.youtube.com/watch?v=fE-P_7-YiVM
https://news.ycombinator.com/item?id=42832155
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.
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.
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.
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?
I appreciate the article, it's cool to see such small differences across all those settings! It says they learned to solder, if you see solder joins that look like those in the first picture, keep learning! Those are some dry joins, which can easily lead to failure, or intermittant signal loss. Soldering can be a touchy sport!
The input latency that has been driving me crazy lately is the screen unblank latency to allow input to a program.
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!
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...
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.
These results are way better than what Dan Luu measured almost a decade ago:
https://danluu.com/input-lag/
Really hope to see a Windows result. What if Windows has a latency of 10 ms+. xD
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.
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.
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.
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.
Yes, we know wayland is not only slower but also with much less features.
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.
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.
This website uses IP address blocking to censor itself, and deserves to be publicly shamed for it. Here's an archive link: https://archive.is/hrYZ6
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!
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
The main issue is with mouse movement rather than clicks tho...
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 wonder how FreeBSD X11 compares to Linux X11
Wow, love this!! This is what makes HN great!
How does Windows compare to this?
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.
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
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!