When I switched to Linux from Windows last year I noticed I had a lot of keyboard input latency only when gaming. It was like I had ~100ms of input latency and it felt exactly the same as playing old school Quake I on a dial up connection without client side prediction turned on. It's like you're skating on ice with a delay when seeing the output vs when you performed the input. This was despite having a solid 60 FPS.
Turns out it was due to a combination of things.
I was using niri (Wayland window compositor) and this input latency was present with or without v-sync turned on. It happened when I was using a 60hz 4k monitor with an NVIDIA GPU.
Then I tried playing the same game on a laptop (same distro and dotfiles) with an AMD GPU and no external monitor. The delay disappeared.
Then I played the same game on that laptop but hooked it up to the 4k monitor and I had the same keyboard input latency only when v-sync was enabled. When I turned off v-sync and capped my FPS then the input latency was reduced by an amount that I could no longer perceive the delay.
Then I put an AMD GPU in the original desktop I was testing and reproduced the same results as the laptop.
However, when I switched to using KDE Plasma with X or Wayland, the keyboard input latency disappeared. This was with the 4k monitor and both NVIDIA and AMD GPUs.
I reported it to niri but it hasn't gotten traction, I just know I can reproduce it on 2 completely different systems with different GPU vendors and hardware when the common ground is having a 4k 60hz monitor hooked up.
I abandoned Windows for a variety of reasons and while I find Linux better in many ways, the graphics and compositing situation is a bummer. To add another example, I was trying to do a screen recording the other day and it was dropping frames like crazy. I don't know who to blame, whether it's Gnome, or Wayland, or OBS, or Nvidia. But the point is my confidence in the entire ecosystem is low. I have plenty of bad things to say about Microsoft, but I think their track record is quite good when it comes to making low latency input and graphics "just work."
With OBS recordings (not streaming) on Linux I occasionally get situations where short but heavy disk or network I/O will cause my webcam's video to get out of sync with my microphone (separate mic from the webcam). This makes it look like my lips are way out of sync with the video. It's something I haven't been able to track down as there's no errors or side effects posted in journald logs.
This is using vanilla Arch with niri. It happens pretty often and I fix it by splitting the audio and video in my editing tool and then shifting the audio track over half a second or so.
I recorded over 1,000 videos on Windows with the same hardware and the above never happened once.
I've been using OBS on wayland, they got captures working really well a few years ago.
But for VR stuff I've been going back to X11, and I was just last night trying to finish a screen capture program on wayland (w/ kde plasma) and idk I just have to do repeated screenshots ana analyze those > horrible fps, but at least I think I got that working finally after many attempts last year.
Gaming is not really an issue now with DEs that help ppl disable compositions and wine/proton.
This is endemic with open source. Nobody owns the hard bugs, nobody does the systems spelunking, and there is little power to make cross-cutting changes. This is why I use a Mac. Not perfect, but better than that no-accountability midden-heap that is Linux.
Maybe AI coding agents will make the situation better, but because open source maintainers are too dim to understand the complex changes the AI makes, and too poor to have their own AIs to help them, they won't take the changes. I make improvements to open source but am forced to keep them to myself.
Except GP said it works fine with all configurations with KDE, which is what most people should be using. I've been using Linux for 15+ years and have never heard of niri.
Take this as a sign that you're out of the loop and your bubble is smaller than you thought. niri is the current hot tiling compositor, and I've switched my laptop over to it recently - away from Plasma - because it's so incredibly slick. It's gathered enough mindshare to have several desktop environments explicitly target it (Dank Material Shell, Noctalia).
In fact there's a whole new cultural wave within open source - tiling Wayland compositors, shockingly featureful DEs based on QuickShell, brand new TUI tools with no CLI or GUI equivalents, and most of it written in Rust.
> I found it hard to believe we couldn’t get a wakeup timer more granular than 1 ms, so I looked at what KWin was using. Indeed, it was passing the sleep duration in milliseconds to a QBasicTimer.
I fixed the same thing in GNOME a few years ago across GLib, GTK, and Mutter/GNOME Shell. It required getting glib onto ppoll() finally.
No X11 because 'KDE drops it' is a rather silly argument for not including it, especially given that X11 is likely to trump Wayland-based systems on this metric. I'm using X11 and will continue to do so until something better comes along. Thus far Wayland is not better, just different and in several ways less functional. Yes, I do use X11 network transparency, sometimes through X2go, other times directly.
I have been having great luck with waypipe (gitlab) as an X11 forwarding alternative (OS X to Ubuntu 24.04). The setup was relatively painless and it 'just worked.' while this might not suit your needs for other reasons I was pleasantly surprised.
Silly author didn't take time to measure on X11, instead 'KDE drops it' author could use older version of KDE or SonicDE fork (rebranded KDE and only X11 support). And while on X11 i'm intresting how XLibre would fare in this metric, because git master of this project feels very snappy.
Wayland is better if you have multiple monitors with high DPI and different fractional scaling settings. But yes, it is less functional than X11 in other ways.
> Originally, I had meant to compare with X11 sessions as well, but with KDE removing them soon, I dropped it.
Last time i checked X11 without a desktop compositor (very important) still provides the least latency of any environment, so even if KDE Plasma (not KDE as a whole AFAICT) drops support, there are other WMs/DEs that will work with it and have minimal latency on desktop.
KDE now supports the newer explicit sync (applications can signal when the frame is ready) and async presentation (fullscreen applications can tear rather than wait for the compositor frame sync). Fullscreen apps can also do direct scanout on Kwin now, and VRR is well supported. X11 w/o a compositor is of course still fewer steps for the data to pass through, but there is no longer anything uniquely available to that flow alone anymore.
> While randomly closing apps, I found the culprit: the Zed editor. Apparently, an open Zed window can add latency to all my other apps even while idle in the background.
Zed definitely does funny things to KWin. It's not the only app that does, but this point in particular would be worth more investigation. I've noticed it causing weird issues with the frame pacing as well sometimes.
> There it was, something about my desktop profile was introducing at least 3 ms of latency [as compared to creating a fresh account]! From here, I tried a bunch of things: plasma-manager to diff my existing profile against a clean one, removing all virtual desktops and disabling all KWin effects and any display scaling. While randomly closing apps, I found the culprit: the Zed editor. Apparently, an open Zed window can add latency to all my other apps even while idle in the background.
Things like this are so maddening. I don't worry too much about performance on Linux, reserving a Windows machine when I want full hardware acceleration and optimization.
Literally just had something similar (seemingly unrelated things affecting each other) happening on Windows yesterday. Was doing some 3D rendering and playing around in Ableton at the same time, the GPU process somehow crashed, even though GPU utilization was at 50% and most of the VRAM was available, and somehow that process crash also brought down the entire Windows USB subsystem, which left it in some weird state where it couldn't connect to my USB audio interface, even after reconnecting it.
It required a reboot to get USB to work again, after a completely unrelated process using mostly the GPU crashed. I let Codex spend 2-3 hours trying to get to a root cause of it, but zero luck, just "USB subsystem became unresponsive when the process crashed"...
It would be interesting to know if the same is true for Intel/AMD. I have one NVIDIA PC and the desktop - not even Games - feels very sluggish on GNOME - I haven't tried KDE yet. On the contrary, my AMD gaming rig subjectively feels very snappy, but I have never measured it.
Executing other actions isn't a feedback loop like moving the mouse pointer; for the mouse pointer you need the feedback from the system before you even get to an actual action. You can press keys on a keyboard blindly, if it doesn't matter where you can even click blindly, but you can't position the pointer blindly. It's closed loop vs. open loop.
I say that because I play some timing tight action games natively on elf(glibc)/linux.
Let's take an example with one of the toughest: Silksong.
I was trying to beat lost lace, her timings were too tight and nearly at each try I was locked in some hardly humanly dodge-able pattern combination. I knew all of her patterns by heart after zillions of tries.
Then, I started to have strong suspicions: I closed all background apps, disconnected the network and try again... did beat her, first try, super ez, like she was transparent to me and slow, I could "read" her and react in time easily.
I am running a Zen2, 12 cores at ~4GHz... and native x11 with xorg, sooo... the main culprit seems to lie in game engine programming and then would not completely tied to wayland programming (don't worry, I am coding my own wayland compositor, so, I am going to move to wayland, well actually designing a 'binary layout' for a wayland compositor to be accurate).
I am now in a Silksong steel soul run, and you bet I'll keep this experience in mind, because when I watch video streams of other people fighting some bosses, I can cleary "read" their moves like it is "slower" and which seems much less "aggressive", but once I fight them on my system, nope, I get a much harder time at reading the boss patterns. The "closing all apps and disconnecting the network cable" did not change a thing here, because I am currently fighting "ez' bosses then I always manages to get rid of them before I get really used to their patterns again... we will see with later and harder bosses.
But this could be another [obvious] culprit: stress. I know I am very, VERY, sensitive to stress: it disrupts severely my mind and worse with very little of it. In other words, I would have "brain fog" while fighting a boss because of stress, and the time I did beat lost lace in one shot ez: I was "testing" something without the stress instead of actually trying to beat her... a abysmal difference.
> I am running a Zen2, 12 cores at ~4GHz... and native x11 with xorg, sooo... the main culprit seems to lie in game engine programming and then would not completely tied to wayland programming (don't worry, I am coding my own wayland compositor, so, I am going to move to wayland, well actually designing a 'binary layout' for a wayland compositor to be accurate).
FWIW, I have similar frame pacing issues with Gnome/Mutter/Wayland with a AMD CPU + Nvidia GPU but that very issue doesn't happen with Xorg at all.
Might surface even larger issues if you go towards Wayland instead :)
In the end, I have strong suspicions on the unity game engine, some weird 'timing' stuff would be happening here, which would disrupt the boss pattern 'timings'. In your case, it seems it is "amplified" by the wayland compositor you are using (I guess you tested various compositor libraries, because many are based on the same libs... where could be hidding some latency, like is xorg but a bit more accute).
But as I said, in my personal case, I have to account for my stress intolerance which is significant, which does not help narrowing down those type of issues. Then, I am probably not one of the right guys to figure out that, but I'll do tests here and there to see if I can get some pertinent info.
I suggest you do the same than me anyway: shutdown all apps, and disconnect your network cable.
The idle Zed culprit fits its GPUI renderer, which has a history of repainting continuously rather than on demand, so the compositor never reaches its idle path and other clients inherit the wakeup cost. Confirming whether the backgrounded Zed window still holds a live frame callback loop would nail it, since that alone keeps KWin out of its low power present timing.
When I switched to Linux from Windows last year I noticed I had a lot of keyboard input latency only when gaming. It was like I had ~100ms of input latency and it felt exactly the same as playing old school Quake I on a dial up connection without client side prediction turned on. It's like you're skating on ice with a delay when seeing the output vs when you performed the input. This was despite having a solid 60 FPS.
Turns out it was due to a combination of things.
I was using niri (Wayland window compositor) and this input latency was present with or without v-sync turned on. It happened when I was using a 60hz 4k monitor with an NVIDIA GPU.
Then I tried playing the same game on a laptop (same distro and dotfiles) with an AMD GPU and no external monitor. The delay disappeared.
Then I played the same game on that laptop but hooked it up to the 4k monitor and I had the same keyboard input latency only when v-sync was enabled. When I turned off v-sync and capped my FPS then the input latency was reduced by an amount that I could no longer perceive the delay.
Then I put an AMD GPU in the original desktop I was testing and reproduced the same results as the laptop.
However, when I switched to using KDE Plasma with X or Wayland, the keyboard input latency disappeared. This was with the 4k monitor and both NVIDIA and AMD GPUs.
I reported it to niri but it hasn't gotten traction, I just know I can reproduce it on 2 completely different systems with different GPU vendors and hardware when the common ground is having a 4k 60hz monitor hooked up.
I abandoned Windows for a variety of reasons and while I find Linux better in many ways, the graphics and compositing situation is a bummer. To add another example, I was trying to do a screen recording the other day and it was dropping frames like crazy. I don't know who to blame, whether it's Gnome, or Wayland, or OBS, or Nvidia. But the point is my confidence in the entire ecosystem is low. I have plenty of bad things to say about Microsoft, but I think their track record is quite good when it comes to making low latency input and graphics "just work."
I know what you mean about "just works".
With OBS recordings (not streaming) on Linux I occasionally get situations where short but heavy disk or network I/O will cause my webcam's video to get out of sync with my microphone (separate mic from the webcam). This makes it look like my lips are way out of sync with the video. It's something I haven't been able to track down as there's no errors or side effects posted in journald logs.
This is using vanilla Arch with niri. It happens pretty often and I fix it by splitting the audio and video in my editing tool and then shifting the audio track over half a second or so.
I recorded over 1,000 videos on Windows with the same hardware and the above never happened once.
Still on X11. OBS just works.
I've been using OBS on wayland, they got captures working really well a few years ago.
But for VR stuff I've been going back to X11, and I was just last night trying to finish a screen capture program on wayland (w/ kde plasma) and idk I just have to do repeated screenshots ana analyze those > horrible fps, but at least I think I got that working finally after many attempts last year.
Gaming is not really an issue now with DEs that help ppl disable compositions and wine/proton.
fwiw I’ve been running lots of stuff under niri with proton Wayland mode for the last ~6 months on nvidia with a vrr display and it’s been fine.
Can’t diagnose here, and not meaning any descent to your experience, just a different user experience for me.
Just throwing this out there but do you happen to have dual monitors where 1 of them is a 4k monitor and the other is not?
This is endemic with open source. Nobody owns the hard bugs, nobody does the systems spelunking, and there is little power to make cross-cutting changes. This is why I use a Mac. Not perfect, but better than that no-accountability midden-heap that is Linux.
Maybe AI coding agents will make the situation better, but because open source maintainers are too dim to understand the complex changes the AI makes, and too poor to have their own AIs to help them, they won't take the changes. I make improvements to open source but am forced to keep them to myself.
Except GP said it works fine with all configurations with KDE, which is what most people should be using. I've been using Linux for 15+ years and have never heard of niri.
Take this as a sign that you're out of the loop and your bubble is smaller than you thought. niri is the current hot tiling compositor, and I've switched my laptop over to it recently - away from Plasma - because it's so incredibly slick. It's gathered enough mindshare to have several desktop environments explicitly target it (Dank Material Shell, Noctalia).
In fact there's a whole new cultural wave within open source - tiling Wayland compositors, shockingly featureful DEs based on QuickShell, brand new TUI tools with no CLI or GUI equivalents, and most of it written in Rust.
>which is what most people should be using
Most people should be running hundreds of megabytes of bloat?
KDE is unuseable on the brand new i3/8gb I run purchased last year.
I mean, the desktop renders, but god forbid I'd like to run more than three firefox tabs...
> I found it hard to believe we couldn’t get a wakeup timer more granular than 1 ms, so I looked at what KWin was using. Indeed, it was passing the sleep duration in milliseconds to a QBasicTimer.
I fixed the same thing in GNOME a few years ago across GLib, GTK, and Mutter/GNOME Shell. It required getting glib onto ppoll() finally.
No X11 because 'KDE drops it' is a rather silly argument for not including it, especially given that X11 is likely to trump Wayland-based systems on this metric. I'm using X11 and will continue to do so until something better comes along. Thus far Wayland is not better, just different and in several ways less functional. Yes, I do use X11 network transparency, sometimes through X2go, other times directly.
Also still on X11 because of xorgxrdp and X11 forwarding.
It would be cool to see this test with a CRT connected to a VGA port (adapters make it slower) and a PS/2 input device.
I have been having great luck with waypipe (gitlab) as an X11 forwarding alternative (OS X to Ubuntu 24.04). The setup was relatively painless and it 'just worked.' while this might not suit your needs for other reasons I was pleasantly surprised.
Silly author didn't take time to measure on X11, instead 'KDE drops it' author could use older version of KDE or SonicDE fork (rebranded KDE and only X11 support). And while on X11 i'm intresting how XLibre would fare in this metric, because git master of this project feels very snappy.
you do have to appreciate how much time he put into doing all the measurements he did take though
Wayland is better if you have multiple monitors with high DPI and different fractional scaling settings. But yes, it is less functional than X11 in other ways.
> Originally, I had meant to compare with X11 sessions as well, but with KDE removing them soon, I dropped it.
Last time i checked X11 without a desktop compositor (very important) still provides the least latency of any environment, so even if KDE Plasma (not KDE as a whole AFAICT) drops support, there are other WMs/DEs that will work with it and have minimal latency on desktop.
KDE now supports the newer explicit sync (applications can signal when the frame is ready) and async presentation (fullscreen applications can tear rather than wait for the compositor frame sync). Fullscreen apps can also do direct scanout on Kwin now, and VRR is well supported. X11 w/o a compositor is of course still fewer steps for the data to pass through, but there is no longer anything uniquely available to that flow alone anymore.
> While randomly closing apps, I found the culprit: the Zed editor. Apparently, an open Zed window can add latency to all my other apps even while idle in the background.
Zed definitely does funny things to KWin. It's not the only app that does, but this point in particular would be worth more investigation. I've noticed it causing weird issues with the frame pacing as well sometimes.
> There it was, something about my desktop profile was introducing at least 3 ms of latency [as compared to creating a fresh account]! From here, I tried a bunch of things: plasma-manager to diff my existing profile against a clean one, removing all virtual desktops and disabling all KWin effects and any display scaling. While randomly closing apps, I found the culprit: the Zed editor. Apparently, an open Zed window can add latency to all my other apps even while idle in the background.
Things like this are so maddening. I don't worry too much about performance on Linux, reserving a Windows machine when I want full hardware acceleration and optimization.
Literally just had something similar (seemingly unrelated things affecting each other) happening on Windows yesterday. Was doing some 3D rendering and playing around in Ableton at the same time, the GPU process somehow crashed, even though GPU utilization was at 50% and most of the VRAM was available, and somehow that process crash also brought down the entire Windows USB subsystem, which left it in some weird state where it couldn't connect to my USB audio interface, even after reconnecting it.
It required a reboot to get USB to work again, after a completely unrelated process using mostly the GPU crashed. I let Codex spend 2-3 hours trying to get to a root cause of it, but zero luck, just "USB subsystem became unresponsive when the process crashed"...
[flagged]
Can you elaborate? I know it's a drive-by but maybe you can articulate.
[flagged]
It would be interesting to know if the same is true for Intel/AMD. I have one NVIDIA PC and the desktop - not even Games - feels very sluggish on GNOME - I haven't tried KDE yet. On the contrary, my AMD gaming rig subjectively feels very snappy, but I have never measured it.
KDE on an AMD card (7900XTX) feels incredibly snappy to use, it's at least on par with windows generally.
I wonder what is Con Kolivas up to these days, he was THE og Linux ui latency guy.
Bitcoin mining. (this is not a joke)
Mouse pointer movement (rather than click) to display update would be amazing to get too… including X11…
this is literally the only thing that ever mattered imo
Would you mind elaborating why? What makes it more important than other inputs?
Executing other actions isn't a feedback loop like moving the mouse pointer; for the mouse pointer you need the feedback from the system before you even get to an actual action. You can press keys on a keyboard blindly, if it doesn't matter where you can even click blindly, but you can't position the pointer blindly. It's closed loop vs. open loop.
Of course you can position the pointer blindly, it's not moving in an unpredictable way.
If you genuinely believe that, I invite you to look up the linearity specification on a few mice and trackpoints and post them here.
duplicate, already posted: https://news.ycombinator.com/item?id=48476462
I don't know the whole tricks and ways that use steamos but it gives very good quality for it's hardware.
I think this is only the top of the iceberg.
I say that because I play some timing tight action games natively on elf(glibc)/linux. Let's take an example with one of the toughest: Silksong.
I was trying to beat lost lace, her timings were too tight and nearly at each try I was locked in some hardly humanly dodge-able pattern combination. I knew all of her patterns by heart after zillions of tries.
Then, I started to have strong suspicions: I closed all background apps, disconnected the network and try again... did beat her, first try, super ez, like she was transparent to me and slow, I could "read" her and react in time easily.
I am running a Zen2, 12 cores at ~4GHz... and native x11 with xorg, sooo... the main culprit seems to lie in game engine programming and then would not completely tied to wayland programming (don't worry, I am coding my own wayland compositor, so, I am going to move to wayland, well actually designing a 'binary layout' for a wayland compositor to be accurate).
I am now in a Silksong steel soul run, and you bet I'll keep this experience in mind, because when I watch video streams of other people fighting some bosses, I can cleary "read" their moves like it is "slower" and which seems much less "aggressive", but once I fight them on my system, nope, I get a much harder time at reading the boss patterns. The "closing all apps and disconnecting the network cable" did not change a thing here, because I am currently fighting "ez' bosses then I always manages to get rid of them before I get really used to their patterns again... we will see with later and harder bosses.
But this could be another [obvious] culprit: stress. I know I am very, VERY, sensitive to stress: it disrupts severely my mind and worse with very little of it. In other words, I would have "brain fog" while fighting a boss because of stress, and the time I did beat lost lace in one shot ez: I was "testing" something without the stress instead of actually trying to beat her... a abysmal difference.
> I am running a Zen2, 12 cores at ~4GHz... and native x11 with xorg, sooo... the main culprit seems to lie in game engine programming and then would not completely tied to wayland programming (don't worry, I am coding my own wayland compositor, so, I am going to move to wayland, well actually designing a 'binary layout' for a wayland compositor to be accurate).
FWIW, I have similar frame pacing issues with Gnome/Mutter/Wayland with a AMD CPU + Nvidia GPU but that very issue doesn't happen with Xorg at all.
Might surface even larger issues if you go towards Wayland instead :)
In the end, I have strong suspicions on the unity game engine, some weird 'timing' stuff would be happening here, which would disrupt the boss pattern 'timings'. In your case, it seems it is "amplified" by the wayland compositor you are using (I guess you tested various compositor libraries, because many are based on the same libs... where could be hidding some latency, like is xorg but a bit more accute).
But as I said, in my personal case, I have to account for my stress intolerance which is significant, which does not help narrowing down those type of issues. Then, I am probably not one of the right guys to figure out that, but I'll do tests here and there to see if I can get some pertinent info.
I suggest you do the same than me anyway: shutdown all apps, and disconnect your network cable.
The idle Zed culprit fits its GPUI renderer, which has a history of repainting continuously rather than on demand, so the compositor never reaches its idle path and other clients inherit the wakeup cost. Confirming whether the backgrounded Zed window still holds a live frame callback loop would nail it, since that alone keeps KWin out of its low power present timing.
[dead]
These vertical labels make me unreasonably mad.
GE 10.34 released March 23th, 5 days after 10.33 - any reason to test with 10.33 in June? Was there a regression?