3 ms·

What Influences Keyboard Input Speed

19 points by MrJagil 5y ago

miguelmurca 5y ago
> You know that argument that people used to have about 30 fps versus 60 fps? “The human eye can’t see the difference” and you don’t need more than 30 frames per second. By now you know better. What a weird opener; if there's a topic that's plagued by anecdotal evidence it's this.
- milkey_mouse 5y ago
  I think that's the author's point. They aren't endorsing the "human eye can't see the difference" thing, it's just become a myth gamers love to debunk. I've heard more people mention it mockingly/sarcastically than I've ever seen claim there is no difference between 30 and 60 fps unironically.
- smoldesu 5y ago
  Maybe, but it sounds like this article is written more for a discerning competitive gamer than someone interested in the internals of a keyboard. To that point, you'd have a pretty hard time arguing that they'd be at a competitive disadvantage for playing at a higher refresh rate.
- munchbunny 5y ago
  The paragraph immediately following what you quoted gives links to the papers and analysis that support these conclusions. Bit of an odd opener, but at least the author backs it up.
- NoPicklez 5y ago
  I don't think it's an odd opener at all as it assumes the reader knows the argument and that by now they should know better (that its not true). It's probably a fairly fitting opener given that it then dives into perception of input latency, which is a less common or discussed topic.
- GuB-42 5y ago
  While 60 fps is definitely better than 30 it is actually a complex subject and in some cases, it doesn't makes that much of a difference. The big reason why gaming may look terrible at 30 fps mostly has to do with temporal aliasing, in other words, the lack of proper motion blur. For example if you look at a car going quickly from left to right in most games, you will see multiple copies of the car instead of a smooth trail, as if it was shot with a strobe light. Modern graphics engines can do motion blur but it is a hack. As an experiment, I tried doing it properly with very simple objects and it definitely looked smooth even at low FPS. But there is a caveat. While it may look good if you are just staring at the screen, things start to fall apart when you start tracking objects with your eyes. The blur becomes apparent. You then have the option to trade blurriness for smoothness by adjusting shutter speed. It is the same kind of trade-off you can have when resizing an image: blurry or pixelated. And then, there are jitter, tearing, artistic considerations, etc...
Scene_Cast2 5y ago
Some folks here might be familiar with QMK. I did a bit of tinkering with an Atmel-based split keyboard with a traditional matrix design (just like almost all custom mech keyboards). My findings: the scan rate is around 200-2000hz (number of times a single key is checked per second). Having a split does lower this number, so does enabling i2c for either split communication or RGB. I measured latency with an oscilloscope by checking the speed from having a key scan to a NumLock LED lighting up on the keyboard. It is variable, from 5ms all the way to 30. I hear that ARM is way better in this regard. And ZMK might be better, too.
- MivLives 5y ago
  Wouldn't ZMK be slower due to having to handle bluetooth? Do you have the full data for each QMK feature written out anywhere? Or is just roughly something like, more features turned = more lag. Did you get faster input when you only used one side of the split?
  - the_gipsy 5y ago
    I think you can run ZMK without bluetooth.
  - Scene_Cast2 5y ago
    I tried a standard config (think BFO-9000 default config). Here are some numbers. Main refers to the left half of the keyboard connected to USB. "Other" refers to the right half, connected via a TRRS cable to the left half. Serial for comms, measurement on main half, other half disconnected. 7-13ms Serial, measurement on main half, other half connected. 8-16ms Serial, measurement on other half, main connected. 9-19ms i2c, measurement on main, other not connected, 5-15ms i2c, measurement on main, other connected, 6-16ms i2c, measurement on other, 10-20ms Not sure if any of the above is stat-sig. Measurement methodology - hook up one probe to the key and trigger on having the key scan seeing "key down". The other probe went to two pins I designated as a NumLock LED. In terms of matrix refresh rate - I remember that enabling reporting to console slowed things down significantly, i2c slowed things down, enabling features slowed things down. No hard numbers unfortunately. ZMK - just because it's a fresher codebase & support for 32-bit only. I did no measurements of ZMK.
smoldesu 5y ago
This is a fantastic article, and a really good breakdown of how keyboards process inputs. Honestly though if 60ms is the worst that has been seen on modern keyboards (a wireless one, at that), then I'd say we're doing pretty good. 60ms is only ~5 frames of delay on a 60hz display, which means your input should register at frame 6 or 7, worst case scenario. That's honestly not bad, and still lower than a lot of wireless game controllers on the market (and some internet connections, for that matter).
SloopJon 5y ago
This is from 2018, with an update from 2019. It primarily focuses on the Wooting one, which is "sold out forever." The key touted advantage of the Wooting one keyboard seems to be optical switches with an adjustable actuation point. It also uses a multiplexer for each row of keys, which is somehow faster than a scan matrix. I don't see an actual test result for the keyboard that includes all of the latency factors discussed. The closest is a link to a tweet by Sunjun Kim. Unlike Dan Luu's measurements, which actually pressed a key, Sunjun triggered the optical switch using an LED, resulting in latency of 4.2 to 9.6 ms, depending on the firmware. According to this post, key travel can add up to 10 ms, which the adjustable actuation is supposed to minimize. That would put the total latency at 10 to 15 ms, which is around what Dan Luu measured for Apple's Magic Keyboard.
milkey_mouse 5y ago
Based on the title, I had hoped this article would be a study of fast typists to determine the most efficient typing styles. While this article is not that, if you also came to the comments looking for something like that, such studies do exist: https://userinterfaces.aalto.fi/136Mkeystrokes/ https://userinterfaces.aalto.fi/136Mkeystrokes/ An interesting conclusion is that "non-standard typists" are catching up to touch typists on standard keyboards. This matches my personal experience as someone whose teachers thought cursive would forever remain more relevant than typing... https://www.sciencedaily.com/releases/2019/10/191002075925.htm https://www.sciencedaily.com/releases/2019/10/191002075925.h... https://news.vanderbilt.edu/2016/10/18/todays-self-taught-typists-almost-as-fast-as-touch-typistsas-long-as-they-can-see-the-keyboard/ https://news.vanderbilt.edu/2016/10/18/todays-self-taught-ty...

19 points by MrJagil 5y ago

> You know that argument that people used to have about 30 fps versus 60 fps? “The human eye can’t see the difference” and you don’t need more than 30 frames per second. By now you know better. What a weird opener; if there's a topic that's plagued by anecdotal evidence it's this.

milkey_mouse 5y ago
I think that's the author's point. They aren't endorsing the "human eye can't see the difference" thing, it's just become a myth gamers love to debunk. I've heard more people mention it mockingly/sarcastically than I've ever seen claim there is no difference between 30 and 60 fps unironically.
smoldesu 5y ago
Maybe, but it sounds like this article is written more for a discerning competitive gamer than someone interested in the internals of a keyboard. To that point, you'd have a pretty hard time arguing that they'd be at a competitive disadvantage for playing at a higher refresh rate.
munchbunny 5y ago
The paragraph immediately following what you quoted gives links to the papers and analysis that support these conclusions. Bit of an odd opener, but at least the author backs it up.
NoPicklez 5y ago
I don't think it's an odd opener at all as it assumes the reader knows the argument and that by now they should know better (that its not true). It's probably a fairly fitting opener given that it then dives into perception of input latency, which is a less common or discussed topic.
GuB-42 5y ago
While 60 fps is definitely better than 30 it is actually a complex subject and in some cases, it doesn't makes that much of a difference. The big reason why gaming may look terrible at 30 fps mostly has to do with temporal aliasing, in other words, the lack of proper motion blur. For example if you look at a car going quickly from left to right in most games, you will see multiple copies of the car instead of a smooth trail, as if it was shot with a strobe light. Modern graphics engines can do motion blur but it is a hack. As an experiment, I tried doing it properly with very simple objects and it definitely looked smooth even at low FPS. But there is a caveat. While it may look good if you are just staring at the screen, things start to fall apart when you start tracking objects with your eyes. The blur becomes apparent. You then have the option to trade blurriness for smoothness by adjusting shutter speed. It is the same kind of trade-off you can have when resizing an image: blurry or pixelated. And then, there are jitter, tearing, artistic considerations, etc...

Scene_Cast2 5y ago

Some folks here might be familiar with QMK. I did a bit of tinkering with an Atmel-based split keyboard with a traditional matrix design (just like almost all custom mech keyboards). My findings: the scan rate is around 200-2000hz (number of times a single key is checked per second). Having a split does lower this number, so does enabling i2c for either split communication or RGB. I measured latency with an oscilloscope by checking the speed from having a key scan to a NumLock LED lighting up on the keyboard. It is variable, from 5ms all the way to 30. I hear that ARM is way better in this regard. And ZMK might be better, too.

MivLives 5y ago
Wouldn't ZMK be slower due to having to handle bluetooth? Do you have the full data for each QMK feature written out anywhere? Or is just roughly something like, more features turned = more lag. Did you get faster input when you only used one side of the split?
- the_gipsy 5y ago
  I think you can run ZMK without bluetooth.
- Scene_Cast2 5y ago
  I tried a standard config (think BFO-9000 default config). Here are some numbers. Main refers to the left half of the keyboard connected to USB. "Other" refers to the right half, connected via a TRRS cable to the left half. Serial for comms, measurement on main half, other half disconnected. 7-13ms Serial, measurement on main half, other half connected. 8-16ms Serial, measurement on other half, main connected. 9-19ms i2c, measurement on main, other not connected, 5-15ms i2c, measurement on main, other connected, 6-16ms i2c, measurement on other, 10-20ms Not sure if any of the above is stat-sig. Measurement methodology - hook up one probe to the key and trigger on having the key scan seeing "key down". The other probe went to two pins I designated as a NumLock LED. In terms of matrix refresh rate - I remember that enabling reporting to console slowed things down significantly, i2c slowed things down, enabling features slowed things down. No hard numbers unfortunately. ZMK - just because it's a fresher codebase & support for 32-bit only. I did no measurements of ZMK.

smoldesu 5y ago

This is a fantastic article, and a really good breakdown of how keyboards process inputs. Honestly though if 60ms is the worst that has been seen on modern keyboards (a wireless one, at that), then I'd say we're doing pretty good. 60ms is only ~5 frames of delay on a 60hz display, which means your input should register at frame 6 or 7, worst case scenario. That's honestly not bad, and still lower than a lot of wireless game controllers on the market (and some internet connections, for that matter).

SloopJon 5y ago

This is from 2018, with an update from 2019. It primarily focuses on the Wooting one, which is "sold out forever." The key touted advantage of the Wooting one keyboard seems to be optical switches with an adjustable actuation point. It also uses a multiplexer for each row of keys, which is somehow faster than a scan matrix. I don't see an actual test result for the keyboard that includes all of the latency factors discussed. The closest is a link to a tweet by Sunjun Kim. Unlike Dan Luu's measurements, which actually pressed a key, Sunjun triggered the optical switch using an LED, resulting in latency of 4.2 to 9.6 ms, depending on the firmware. According to this post, key travel can add up to 10 ms, which the adjustable actuation is supposed to minimize. That would put the total latency at 10 to 15 ms, which is around what Dan Luu measured for Apple's Magic Keyboard.

milkey_mouse 5y ago

Based on the title, I had hoped this article would be a study of fast typists to determine the most efficient typing styles. While this article is not that, if you also came to the comments looking for something like that, such studies do exist: https://userinterfaces.aalto.fi/136Mkeystrokes/ https://userinterfaces.aalto.fi/136Mkeystrokes/ An interesting conclusion is that "non-standard typists" are catching up to touch typists on standard keyboards. This matches my personal experience as someone whose teachers thought cursive would forever remain more relevant than typing... https://www.sciencedaily.com/releases/2019/10/191002075925.htm https://www.sciencedaily.com/releases/2019/10/191002075925.h... https://news.vanderbilt.edu/2016/10/18/todays-self-taught-typists-almost-as-fast-as-touch-typistsas-long-as-they-can-see-the-keyboard/ https://news.vanderbilt.edu/2016/10/18/todays-self-taught-ty...