I recently measured it with my phone's camera in slow motion mode. The system is an AMD Ryzen 1800X with AMD R9 280x GPU, KDE Plasma with KWin window manager in compositing mode. Key press to screen output latency was ~33 millseconds (90 fps recording, so increments of 11) in KWrite.
The computer feels plenty responsive with that latency, and I hate latency...
It is a full stack real world result - for comparison purposes it makes sense to measure only the software as in the article, but in reality you want to optimize everything. Especially screens can be quite bad - tens of milliseconds, up to 100 in the worst. USB lag is usually quite low - when I measured it once for low-latency serial comm it was usually < 2 ms.
33 ms is two frames, if your monitor is at 60 Hz. If you tried vscode or other electron app, it might be 49 ms (3 frames). These are the numbers I'm getting from 1900X with Nvidia 1080 GPU, Gnome3, 4k@60hz, but without measuring latency of the keyboard itself.
Modern keyboards are another part of the problem. They can also take their sweet time since keypress until packet appears at the USB bus. See https://danluu.com/keyboard-latency/
The problem is often in keyboard controller, not in the interface. Apple managed to get fastest keyboard with only 15ms lag; other may be order of magnitude slower.
It’s a common myth that denouncing needs to meaningfully affect latency. It does not. It will affect maximum repeat rate, but you can pretty much report an event the moment you see an edge.
Replace with _any_ keyboard manufacture.. Similarly, while your keyboard may advertise USB2 or even USB3, the actual key-press USB interface is always running at USB 1 low speed (1.5Mbit).
I spent a fair amount of time trying to find a keyboard to work on a device that I have that only works with high speed devices, 30 or 40 keyboards later I gave up... If someone actually knows of such a thing I would be interested. Same basic problem with mice.. I guess the thought-process is that hey USB2 supports split transactions, and the keyboard/mouse won't actually generate even 1.5M bit of data, so we are going to continue to sell the same basic mouse/keyboard interfaces we were selling 20 years ago wrapped in styling variations.
PS: Some of the physical button keyboards I found with configurable colors/etc, usb hubs, do support USB3... For the color controls, or hub. The keyboard endpoint is still at low speed...
Likely because they want to implement the minimum necessary HID spec (or, in a nicer tone, the HID spec with the most compatibility), which would be the one supported by the BIOS.
I don't understand why someone hasn't come out with a dedicated keyboard chip yet. If it's cheap enough you don't need to run all the keys to a single chip, you could have multiple chips that all talk over a serial bus to one that it designated the master.
true, but adding another link (microcontroller) in the chain is going to add delay anyway. I think the original suggestion was pointless: instead of adding more microcontrollers you can just replace the main uC with the one that has enough pins. The reason this is not done is uCs with >100 pins are usually more powerful and expensive, so you can't just pay for more pins -- you also have to pay for more processing power and features you don't need.
Denouncing shouldn’t add lag. On the first closure detection you can send the key down code. You then need some debounce logic to decide when to send the key up code, but after the key is solidly down you are again in a state to send the key up code as soon as the up begins.
The only time there should be lag is when a very short keypress happens, the key up might be delayed while the controller rules out bounce.
I'm getting min 18.5-avg 24.3-max 35.2 ms in vscode on 2015 rMBP. However, the test won't finish and Typometer complains ("Previously undetected block cursor found"). In Emacs, it won't run at all.
Yeah, that seems to be a weak point of some visual measurements, especially when laptop and other scissor keyboards score better than older switch-based ones.
I don't - just filmed keyboard and screen together; key down is easy to see. I have a quality keyboard (Fujitsu KBPC PX eco) connected by PS/2, and as stated above I'd expect little extra latency from USB. As measured, anyway, there is no space for significant keyboard lag in the result.
The reason why I measured latency was that I seemed to notice a change after changing GPU driver kernel options. End to end was easiest to measure. The result was close to the theoretical minimum so I stopped there.
A recent iphone, the samsung s8 and the pixel phones can record at 240fps, which gives you much better precision if you have access to that kind of phone.
It is a full stack real world result - for comparison purposes it makes sense to measure only the software as in the article, but in reality you want to optimize everything. Especially screens can be quite bad - tens of milliseconds, up to 100 in the worst. USB lag is usually quite low - when I measured it once for low-latency serial comm it was usually < 2 ms.