What influences keyboard input speed (2018)
next.wooting.ioI don't get the multiplexer vs matrix argument. Wouldn't multiplexers add their own problems? You need to wait for the output to become stable when you change the input select. I'm guessing as part of the scanning, they are changing the SEL of the muxes and then waiting? The article seems to gloss over that completely.
I would have thought they'd be super cheap anyway, if you're looking at $200 keyboards, spending a dollar or so to get a few muxes doesn't seem like a big deal. If they were truly better, I imagine every keyboard enthusiast would be using them.
Edit: I guess since they have multiple muxes, they change the SEL well in advance before scanning the key. So it just requires "clever" scheduling. Just like a matrix requires "clever" diodes, I really don't buy that muxes are an advantage here.
Disclaimer: somehow graduated with an EE, but am an idiot.
Multiplexers are only better for N-key rollover.
The settling time of the switch is the same, regardless of the scanning technique used.
But with a multiplexer, the output of one switch has no impact on the output of another – you can independently actuate each key. They are all essentially isolated switches with individual pull-up resistors.
The multiplexing can be done in a number of different ways, none of which need to be particularly clever. The simplest scheme is simply to connect each key directly to a GPIO on a large-pinout microcontroller, like a TQFP-144. The fewer the keys, the less GPIO you need.
This is the best way to build a keyboard, since input can be done at the clock speed of the MCU, and debouncing can happen on all pins in parallel simultaneously.
Slightly more complex would be to use a smaller MCU with a multiplexer on each input, like a 4051 or 4067. The switching time is like 20-50ns on these parts, so while it's not quite as fast as a GPIO register read, it's still pretty quick, more than fast enough for keyboards.
If you really wanted to get crazy, you could read each switch with a high speed ADC and use an ML model to debounce the keys. But at that point, you're better off just using optical switches which don't really need debouncing.
Okay, I can kind of see how it makes a difference for n-key rollover.
> The switching time is like 20-50ns on these parts, so while it's not quite as fast as a GPIO register read, it's still pretty quick, more than fast enough for keyboards.
I guess my point was that if you change which input you're reading from the mux and then immediately sample with the MCU, you'll get unstable data. 50ns is 20MHz, I can easily see an MCU used in a keyboard being fast enough to hit this.
It's obviously easy to work around, but so is ghosting.
This keyboard actually uses optical switches and reads them using an ADC. It does do debouncing but with orders of magnitude shorter delay.
optical switches don't really use debouncing, it's more of a schmitt trigger where there are different voltage thresholds for key down and key up. As the optical gate closes, the voltage on the phototransistor lowers proportionally to the degree of closure So the only way to get a key down voltage level is to actually travel the switch to the down position, and likewise for key up.
> You need to wait for the output to become stable when you change the input select.
The switching time of multiplexers is on the scale of 100 nanoseconds, so it's negligible (assuming there's no extra RC components behind the multiplexer to lengthen its settling time further, a reasonable assumption for pure software denouncing).
People claiming rhythm games require low latency is a pet peeve of mine.
Rhythm games have knobs to offset the music, most even have sync wizards (tapping to the beat). If you have 200ms input delay, just have the game offset the music by -200ms. It's really not a problem
When you need to add that extra latency it can feel bad. Especially in games where you're hitting tight (~30ms) timing windows. Having your button presses be several timing windows ahead of what you're trying to hit adds mental load that's noticable to me at least.
I got a cabinet for one of my favorite arcade rhythm games, Pop'n Music, a couple of years ago. It's older Firebeat hardware so it's a non-general purpose system specifically built for arcade music games not running a general purpose OS. I was surprised by how much better it felt than the newer versions of the game which run on Windows XP with inherent extra latency in its audio playback. (Other games by the same developer have taken advantage of lower latency audio apis in newer versions of Windows but iirc Pop'n hasn't gotten off XP yet.)
Adjustable offset helps, but the greater the latency the more disconnected you feel from the beat. 200 ms would be absolutely unplayable. To put that into perspective, 200 ms is an eighth note when the music plays at 150 bpm. So every time your fingers move you have to wait an eighth note to see and hear the result.
For OSU I built a 2-key keyboard (not to improve timing but to avoid destroying my WASD one that was expensive).
It's got a 16 mhz mcu in a busy-loop reading two CPU pins.. It should be pretty fast and consistent (but I don't know how much time the actual USB protocol stuff takes, and I suspect that more jitter is introduced in the OS anyway)
http://dusted.dk/pages/osukeys/
Yes, I could have used interrupts, but I didn't.
Mechanical keyboards almost universally have diodes that make a matrix never exhibit ghosting, so this article is straight wrong there.
The exception is Model M keyboards, which actually use a membrane instead of a PCB.
Actually, no keyboard exhibits "ghost keys" — phantom key presses. The difference between methods of "anti-ghost"ing is whether ghost keys are avoided completely (e.g. using diodes), avoided for some key combinations (e.g. "gaming optimised matrix") or just suppressed (detected and blocked).
99.9% of mechanical keyboards made in the last decade avoid ghost keys by using diodes, yes, primarily because they have been intended for gaming.
However, diodes are not at all universal in mechanical office keyboards, even if they use discrete switches and a PCB. If you'd look at vintage mechanical keyboards, you'll find that while many have them, many don't. Cherry even still makes some older models with Cherry MX switches and 2-key rollover.
> Mechanical keyboards almost universally
You’re going to have to be more precise than this. Most “mechanical” keyboards from the 80s–90s do not (the Model M is not at all exceptional in this sense). I would guess most of the more recent ones (marketed to ordinary typists) don’t either.
For enthusiast-/gamer-targeted keyboards from the past few years you could be right.
Surely 30 year old keyboards constitute a tiny niche of extant keyboards.
The majority of extant keyboards at this point are probably laptop keyboards, followed by cheap rubber membrane boards. “Mechanical” keyboards are a small niche. I would guess desktop mechanical keyboards for commercial/office use are probably still bigger than the consumer market, but I’m not really sure.
I don’t have any data about the number of keyboards still in active use / still in working order, but the number of mechanical keyboards produced 2–3 decades ago was probably an order of magnitude larger than the number produced today. And while most have been scrapped by now, keyboards are pretty durable.
The past few years has seen significant growth in the number of people buying mechanical keyboards though, so you could be right that new devices make the majority.
Same topic: https://news.ycombinator.com/item?id=28399883 "Keyboard Latency (2017) (danluu.com)"
The best optical linear switches in 2022 have a response time of 0.2 ms. I think we hit the point of rapidly diminishing returns long ago.
Any hobby will eventually devolve into absurdity. This happens much quicker if marketing departments are involved. :)
I’m happy with my Topre keyboards (in particular All 30 gram keys) with their n key roll over (?).
Article was good, worth reading.
Does it matter if you're not gaming? I just type without looking; my eyes rest on the screen but I don't read it while typing, and even frequently have my eyes closed.
I can imagine how this matters to gamers -- just asking about the "normal" use of the keyboard.
I appreciate stuff like this because while I’m never gonna spend $200 on a keyboard it’ll eventually filter back to us $30-$40 keyboard users.
I think you might find even jumping to the $60 - $80 bracket does wonders, and remember, quality products tend to last.
> Depending on the quality of the switch, the bouncing time will vary. The most popular Cherry MX switches have a bouncing time of up to 5ms. This means the software delay should at least be 5ms or higher.
That is incorrect. You can register and send "key held" input on the first bounce, immediately, then just ignore the key for the debouncing interval. Probably still want some capacitance on the input to not get triggered by any EMI tho.
That moves the latency to key depress but as there is a very little chance someone presses key for less than 10ms it doesn't matter.
The "interrupt, wait, interrupt, send signal" method might be easier to code I guess, especially if you just have few buttons and use hardware interrupts for them.
The sad thing is that I've used several mechanical keyboards that very clearly do the wrong thing the article suggests. Debouncing on keydown is super obvious and really painful as a user.
Why does debouncing increase latency? Can’t they report the keypress immediately on the first signal spike, and then use the debounce timer to ensure that no additional presses are reported within the debounce interval?
Or are switches generating spurious signal spikes even when left untouched? That would explain why they need to delay the keypress…
They can, and article is just bad, as it completely ignores that and the fact you can use diodes to remove ghosting.
I've been typing for a long time, and I think I type pretty quickly. I've never felt that my keyboard is slower than my typing. At least not since ZX-81 days.
Maybe you’re getting slower at the same rate as computers ;-)