Hacker News Reader

Comment by iamevn | Hacker News Reader

I'm surprised by the section on including key travel time in the latency measures. Wasn't the Apple 2 keyboard about comparable in travel distance and resistance to today's typical mechanical keyboard switches?

I still can't find it in me to like the Apple Magic keyboard because I feel like my fingers are smashing into a metal plate hundreds of times a minute. That's a me problem though and others just have better form.

Now I'm curious about the latency of the stuff I've put on teensys in my own custom keyboards/controllers and will need to resist the urge to go shopping for a scope.

Also wondering how much PS/2 vs USB matters.

View on HN

>Also wondering how much PS/2 vs USB matters.

I had to get to grips with the USB spec when designing my USB scope [1].

Adherence to the USB spec itself doesn't necessarily create human-perceptible latency; HID frames can be transmitted every 1 ms and could be parsed in a negligible number of CPU cycles on an embedded machine with USB-OTG and no operating system.

Like everything, the noticeable lag appears because the application-layer software is going through 15 layers of abstraction rather than talking directly to the input device, and this can become as complex and bloated as it wants.

[1] https://espotek.com/labrador/ (In case you become unable to resist your scope urge :P)

Thanks for sharing, that looks like a great hobbyist tool.

You're welcome. Not going to pass up an opportunity to shill my business on HN. :P

Thanks for sharing.

Micro typo alert on the Labrador landing page: "Everything was been" -> "Everything has been" or "Everything was", I guess. :)

A lot of time can be wasted with poor debounce implementations. Cherry switches claims <8ms bounce IIRC, but you only need to debounce one of the edges. So as soon as you see the key start bouncing, you know it is activated, so you can immediately register the press, then do debounce. That way you only delay the registration of the release. By using a shift register you can also minimize it to the actual bounce time, not a predetermined delay. I (personally) don't know of any commercial keyboards that implements it this way, but given that their software is closed source, it is very possible that some do use this algorithm.

Not only that, but the matrix scanning could be done via interrupts instead of via polling as is typically[0] done. An interrupt could fire on a level shift of any of the column GPIOs, then the MCU needs to search the rows to find the selected key. After the interrupt the MCU will need to poll until all the keys are released. So there's another source of latency that could be improved.

I think the only source of polling left is in USB, but I think that's inherent to the USB protocol (someone correct me if I'm wrong here). Without the USB polling I think it would be possible to have key-press-to-USB-packet completely interrupt driven which should make the latency in the keyboard itself negligible.

[0]: I say typically but like you said a lot of implementations are closed source, so who knows. All of the discussions I've seen on matrix scanning use the polling method, and the open source implementations use polling as well (e.g. Keyberon[1]).

[1]: https://github.com/TeXitoi/keyberon-grid/blob/master/src/bin...

The few open source implementations I have looked at scan the matrix as fast as the processor allows. So using interrupts can reduce power consumption a lot, but depending on the actual matrix layout, probably not any worthwhile speedup in the nominal case, as you still have to scan the rows after the interrupt.

AFAIR, the USB poll rate is a function of USB rate, and what the endpoint reports/requests. Low-speed, full-speed and high-speed all have different poll rates.

It’s counter-intuitive (and you probably already know this but for the benefit of others) but depending on frequency and CPU availability, polling can have a lower latency than interrupts. You just have a much smaller window of time to execute your handling code (unless you don’t care).

It’s actually partially why (some?) hard real-time systems eschew interrupts altogether. They introduce a source of non-determinism into the mix as an interrupt handler can stall out non-interrupt performance-sensitive code (or starve it).

That's what I thought when I set my handwired keyboard firmware settings using QMK, just trigger on the edge. But then occasionally switching the exhaust fan switch in the room next door would make errant keystrokes, not cool, so I decided I could live with a few ms more latency. Maybe a proper PCB like a bought keyboard could be more noise immune though.

I made an implementation of what I describe for TMK years ago. There is possibly a problem with the hardware design of your keyboard, probably too weak pull ups coupled with EMI susceptibility, of the hard-wiring. I am having no issues with false triggers on my end.

It was probably the best you could do in your position, but debounce is a hack to work around EMI and not the actual solution. Ideally, the circuit should be electrically resilient to EMI and the debounce should only be handling mechanical noise from the switch itself and not concern itself with any outside interference.

> I'm surprised by the section on including key travel time in the latency measures. Wasn't the Apple 2 keyboard about comparable in travel distance and resistance to today's typical mechanical keyboard switches?

>>A major source of latency is key travel time. It’s not a coincidence that the quickest keyboard measured also has the shortest key travel distance by a large margin. The video setup I’m using to measure end-to-end latency is a 240 fps camera, which means that frames are 4ms apart. When videoing “normal" keypresses and typing, it takes 4-8 frames for a key to become fully depressed. Most switches will start firing before the key is fully depressed, but the key travel time is still significant and can easily add 10ms of delay (or more, depending on the switch mechanism). Contrast this to the Apple "magic" keyboard measured, where the key travel is so short that it can’t be captured with a 240 fps camera, indicating that the key travel time is < 4ms.

Yeah, I don't get that either.

It should be the time a key makes contact to the time the signal is sent. If I were to design that I would make an external trigger that connects to the solder pads of the key and start the timer on the logic analyser.

I like my keys with a lot of travel and a good thunk when they send the signal.

This would penalize them extensively for doing exactly what I want.

I mean if you want fast keyboards capacitive key caps would be even faster, but I've yet to meet anyone who has replaced their keyboard with a tablet.

Because typing on a capacitive tablet would be tiring. You can't rest your fingers anywhere without registering a touch, so you lose all the benefits of a home row. You need to be able to distinguish between resting contact and a positive press, and capacitives would make that hard. Not impossible, but not easy either, and tablets today don't do it.

Not sure what you're explaining? I'm just pointing out that their metric is extremely flawed and can be easily gamed by an inferior solution. Like the Apple Magic.

I'm not seeing how its "gaming the metric" to include travel time of the key on a keyboard. Typing is ultimately a physical interaction with an interface, not just data transmission over a wire. Therefore, if we are measuring the latency of the input we must include physical travel time. Consider an extreme example, if each "key" used a control lever, like the type on a tractor or used to control thrust in an airplane, we'll just say 90 degrees with a radius of 8", with a significant amount of linear activation force(relative to a keyboard). It wouldn't matter if the device had response time that was virtually instant when you reached the activation point, the input latency of this system would be so significant as to be impractical for most typing tasks. If anything excluding travel time would be gaming the metric.

>I'm not seeing how its "gaming the metric" to include travel time of the key on a keyboard.

Because if we remove travel time by using a capacitive keyboard you end up with something that is objectively a worse keyboard. Replacing the capacitors with strain gauges so you can rest your fingers on the home row without activating them results in an worse keyboard yet again.

Any metric that when optimized produces an objectively worse product is a bad metric and optimizing a bad metric is gaming it.

It’s not an “objectively worse product”. It’s a product that does well on some metrics (size, apparently latency) and does poorly on others (famously, durability). Then there’s the completely subjective aspect of what sort of feel you want from the keyboard — which is why Cherry has a bazillion different switch types (and why I have a tester set on my desk right now because I’m trying to decide on a new keyboard).

Prioritising each of those is up to you. Your priorities are different from mine, and my preferences don’t make your keyboard of choice “objectively worse” overall.

This is quite literally about as subjective as it gets. You like a thunk when you type, and there isn’t anything wrong with that, but other people really like short stroke keys, and they might even find the keyboard you described delightful, especially—I would imagine— if it was paired with a nice, timely audio queue and haptics.

I know several people who absolutely loved the butterfly keyboards, and I found them a joy to type on in short bursts. However I, personally, have too heavy of hands/fingers for them and prefer ~80g actuation force so I can completely rest my fingers on the keys without activating them.

>if it was paired with a nice, timely audio queue and haptics.

So now you have extra latency between key activation, audio activation and haptic activation. You know what gives you all of those for free and ensures they are always timed correctly?

A physical key.

>I know several people who absolutely loved the butterfly keyboards, and I found them a joy to type on in short bursts. However I, personally, have too heavy of hands/fingers for them and prefer ~80g actuation force so I can completely rest my fingers on the keys without activating them.

Activation force and key travel distance have nothing to do with each other. I'm half tempted to build a strain gauge keyboard with zero travel just so people can pay me to see how bad they are.

The less physical feedback a keyboard gives you the more typos you make using it. Arguing that keyboards which encourage you to make more typos are good is as stupid as saying that camouflaged stop signs are as good as the old fashioned red ones.

This isn't an opinion, this is objectively true.

>The less physical feedback a keyboard gives you the more typos you make using it. Arguing that keyboards which encourage you to make typos are good is as stupid… this is objectively true.

This seems like a tenuous assumption. It completely ignores the main point I have, which is that different users have different preference. That’s why I brought up activation force, because my problem with the magic keyboard wasn’t the feedback, which I absolutely loved, but the activation force of the keys. I and many others have never found the amount of feedback on the Magic keyboard to be inadequate. You are projecting your personal perception that a large amount of key travel distance makes you type more accurately and is therefore desirable(to you), into an axiomatic truth about the nature of keyboards for everyone(i.e. that significant travel distance is needed to make a high quality keyboard and therefore shouldn’t be counted in a metric about the latency of inputs).

I'll make you a keyboard with 80g zero travel keys for $1,500 if you think they are so great.

There is no expectation of a character appearing on screen until the click. So the latency between key touch and click has no feel of latency to a person.

The flip side is that there is no expectation of a character appearing until the click happens. So a keyboard with a click which reduced latency by a lot would start showing characters before the click occurred -- and this would be incorrect behavior.

If I'm touch typing on a keyboard with full travel distance, I may have more than one key in motion at the same time, so the latency of each keypress doesn't exactly add.

Additionally, if you're talking gaming keyboards as article goes into, you don't time your "shot" for when you first touch the key. The timing of the shot is relative to when the click happens. You might even milk the key the same way you milk a trigger on a gun. Or if you're in a rapid fire use you flutter back and forth across the threshold with a clickless switch like cherry reds, and you don't use the full travel of the key. Either of these the latency measure in the article doesn't line up with real world use.

You're not waiting for character to appear between starting pressing next key - if you touch type you have multiple keys "in-flight". So, the latency is less than appears - since bulk of that time is eaten by the fact that you start to press next key before the first one is even registered.

It’s not “gaming the metric” if somebody comes up with the metric and methodology after you’ve already sold the product.

Also, it’s a bit weird to say the metric is flawed because it produces a result you don’t like.

Literally the last half of your last sentence. The reason nobody uses capacitive tablets as keyboards has nothing to do with speed, however it's measured.

I think you are right that there are good keyboards that would get penalized in this metric. But I'm not sure that it makes sense to try to improve the measurement system -- is is possible that this just isn't a very important measurement.

> Also wondering how much PS/2 vs USB matters.

Ben Eater has a great video on this:

https://www.youtube.com/watch?v=wdgULBpRoXk

There’s a great video here that goes through all this - the gist is that USB keyboards specify what polling rate to use, 1000hz for the best ones, maybe 125hz for the cheaper ones. An interesting thing about ps/2 is that even though it doesn’t have to wait for the keyboard to poll it transmits data at much slower speed than USB (khz vs mhz) which somewhat offsets the advantage it gets from being interrupt driven

https://m.youtube.com/watch?v=wdgULBpRoXk

edit: ah, sorry, I see someone's posted a link to this video already!

I agree with you about the apple magic keyboard. It hurts quite badly!

That bit made no sense. It might have made some sense if it was measured from the moment you get physical feedback from the keyboard that the key has been pressed. But I suspect that this isn't as straight forward as it is tempting to believe. (For instance if the mechanical feedback and the moment of contact do not occur at the exact same moment)

Reply on news.ycombinator.com