[HN Gopher] What influences keyboard input speed (2018)
___________________________________________________________________
What influences keyboard input speed (2018)
Author : celesian
Score : 57 points
Date : 2022-10-13 13:09 UTC (9 hours ago)
(HTM) web link (next.wooting.io)
(TXT) w3m dump (next.wooting.io)
| xani_ wrote:
| > 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.
| chowells wrote:
| 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.
| kangalioo wrote:
| 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
| iamevn wrote:
| 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.)
| snmx999 wrote:
| 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.
| [deleted]
| gumby wrote:
| 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.
| dusted wrote:
| 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.
| aaaaaaaaaaab wrote:
| 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...
| xani_ wrote:
| They can, and article is just bad, as it completely ignores
| that and the fact you can use diodes to remove ghosting.
| dboreham wrote:
| 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.
| aaaaaaaaaaab wrote:
| Maybe you're getting slower at the same rate as computers
| ;-)
| CarVac wrote:
| 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.
| jacobolus wrote:
| > 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.
| thfuran wrote:
| Surely 30 year old keyboards constitute a tiny niche of
| extant keyboards.
| jacobolus wrote:
| 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.
| Findecanor wrote:
| 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.
| math-dev wrote:
| I'm happy with my Topre keyboards (in particular All 30 gram
| keys) with their n key roll over (?).
|
| Article was good, worth reading.
| twobitshifter wrote:
| 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.
| nomel wrote:
| Any hobby will eventually devolve into absurdity. This happens
| much quicker if marketing departments are involved. :)
| vxNsr wrote:
| 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.
| gjvc wrote:
| I think you might find even jumping to the $60 - $80 bracket
| does wonders, and remember, quality products tend to last.
| sllabres wrote:
| Same topic: https://news.ycombinator.com/item?id=28399883
| "Keyboard Latency (2017) (danluu.com)"
| doix wrote:
| I 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.
| segfaultbuserr wrote:
| > _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).
| jmole wrote:
| 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.
| camtarn wrote:
| This keyboard actually uses optical switches and reads them
| using an ADC. It does do debouncing but with orders of
| magnitude shorter delay.
| jmole wrote:
| 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.
| doix wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-13 23:01 UTC)