Posted by hoechst 5 hours ago
https://www.youtube.com/watch?v=vOvQCPLkPt4
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!
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.
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.
They also have repeated measurements which improves the precision.
>Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.
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.
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...
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).