What influences keyboard input speed (2018)

I don&#x27;t get the multiplexer vs matrix argument. Wouldn&#x27;t multiplexers add their own problems? You need to wait for the output to become stable when you change the input select. I&#x27;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.<p>I would have thought they&#x27;d be super cheap anyway, if you&#x27;re looking at $200 keyboards, spending a dollar or so to get a few muxes doesn&#x27;t seem like a big deal. If they were truly better, I imagine every keyboard enthusiast would be using them.<p>Edit: I guess since they have multiple muxes, they change the SEL well in advance before scanning the key. So it just requires &quot;clever&quot; scheduling. Just like a matrix requires &quot;clever&quot; diodes, I really don&#x27;t buy that muxes are an advantage here.<p>Disclaimer: somehow graduated with an EE, but am an idiot.

People claiming rhythm games require low latency is a pet peeve of mine.<p>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&#x27;s really not a problem

For OSU I built a 2-key keyboard (not to improve timing but to avoid destroying my WASD one that was expensive).<p>It&#x27;s got a 16 mhz mcu in a busy-loop reading two CPU pins.. It should be pretty fast and consistent (but I don&#x27;t know how much time the actual USB protocol stuff takes, and I suspect that more jitter is introduced in the OS anyway)<p><a href="http:&#x2F;&#x2F;dusted.dk&#x2F;pages&#x2F;osukeys&#x2F;" rel="nofollow">http:&#x2F;&#x2F;dusted.dk&#x2F;pages&#x2F;osukeys&#x2F;</a><p>Yes, I could have used interrupts, but I didn&#x27;t.

Mechanical keyboards almost universally have diodes that make a matrix never exhibit ghosting, so this article is straight wrong there.<p>The exception is Model M keyboards, which actually use a membrane instead of a PCB.

Same topic: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28399883" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28399883</a> &quot;Keyboard Latency (2017) (danluu.com)&quot;

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.

I’m happy with my Topre keyboards (in particular All 30 gram keys) with their n key roll over (?).<p>Article was good, worth reading.

Does it matter if you&#x27;re not gaming? I just type without looking; my eyes rest on the screen but I don&#x27;t read it while typing, and even frequently have my eyes closed.<p>I can imagine how this matters to gamers -- just asking about the &quot;normal&quot; 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.

&gt; 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.<p>That is incorrect. You can register and send &quot;key held&quot; 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.<p>That moves the latency to key depress but as there is a very little chance someone presses key for less than 10ms it doesn&#x27;t matter.<p>The &quot;interrupt, wait, interrupt, send signal&quot; method might be easier to code I guess, especially if you just have few buttons and use hardware interrupts for them.

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 <i>additional</i> presses are reported within the debounce interval?<p>Or are switches generating spurious signal spikes even when left untouched? That would explain why they need to delay the keypress…