Oh man, is that why pressing "iu" quickly would come out as "ui"? I know I press them correctly, because I use the middle and ring fingers together simultaneously, with the longer finger obviously striking one key first, yet they'd always come out wrong.

Wow. All these years it's been the keyboard, not me. Kinda mildly infuriating.

Yeah, it really is, and people didn't believe me when I said with certainty that it was the keyboard's fault.

Wow. I'm surprised they don't do this on the component level. When I was working in embedded, I considered software debouncing a lazy hack. I'd rather sanitize the data before it hits software.

Firstly, hardware debouncing is a bit awkward to implement on a multiplexed matrix, since you need a debouncing circuit for each of your inputs (meaning about a dozen or so of them).

More importantly though, software debouncing offers greater flexibility. For keyboards, you usually[1] want to implement an asymmetric "eager" mode, where a key press gets registered immediately and only the key release is debounced. Since software usually does stuff on the key down event, this works to reduce latency.

[1] Well, that's what the various enthusiast mechanical keyboard firmwares do, I am not so sure that generic $random_corp keyboards do care...

There's nothing wrong with software debouncing. Almost all fancy DIY exotic keyboards use software debouncing effectively.

In fact it's more customizable for quicker response than hardware RC debouncing.

There is, however, something wrong with shitty debouncing software.

It looks like he keyboard state is read by the driver, rather than the keyboard sending the state to the OS. How would you denounce on a hardware level with such a setup?

One way is a RC circuit - where the switch (the keyboard button) in series with a resistor then charges a capacitor. You specify the ratio of resistance to capacitance so it takes long enough for the switch to stop bouncing before the capacitor output rises to the sense level of your digital input.

But if you want to reduce hardware cost, you can eliminate many capacitors and resistors by doing it in firmware instead.

Computer keyboards tend to have switches in a matrix so that only (columns + rows) number of GPIO pins would be needed on the keyboard controller. Each column gets strobed at once in turn, and the rows sensed.

Cherry once made a software/hardware hybrid but it didn't have any advantages compared to software debouncing, and it needed more power, so there was only one model.

If I understand it correctly, debouncing with a capacitor delay events somewhat. With software debouncing (done right) you are only required to have a minimum time between the press and release events.

Yeah, I get where you're coming from, but a few dozen SMD caps and resistors ordered in that kind of bulk probably raises the cost by a penny. Of course you do technically have more points of failure I guess.

I had clients who were going to bargain for less than a penny

For ten million units, a penny is $100,000. You could give an engineer an entire quarter to come up with a software debounce for less than that.

That shit adds up. BOM costs are everything for consumer goods.

I've always wondered why the same logic doesn't apply to using a commercial BIOS. Doesn't the per-unit cost for someone like Compal add up to more than the value in using a customized Phoenix firmware? Even with UEFI the branded option is generally used.

And if you make $10 on each of those that's .1%. Or even if it's only $1 that's 1%. So be it!

I don't want to encourage shitty design for pennies at any level.

Stop making shitty shit.

There aren’t that many 1% in 100% or even that many 0.1% in 100%.

Saving a penny on the keyboard will be one of hundreds of places where a penny was saved. Good engineering and product design is about trade offs and compromise, not taking absolute positions about what’s shitty or not.

Exactly. Opportunity cost. Maybe saving a penny on this portion of the keyboard let’s them spend a penny on some other part of the design that might have even more positive customer impact.

I’m not too familiar with hardware, but would you be able to differentiate between the unpressed state with such a scheme?

Typically in a 5v system you'd treat capacitor output voltages under 2.3V as pressed and over 2.3V as released. There is a "pullup" resistor and the switch is wired to "pull down" the circuit towards ground, through the mentioned resistor.

Most Microcontrollers have the pullup resistor built in. Modern ones even let you turn the pull-up feature on and off per pin with a SFR (a special register /fixed memory address you can write to where you change hardware settings). Often you can also choose between reading a pin or driving it as an output.

The most important thing to know about debouncing is that any hardware switch bounces from 50-200 times over a very very short interval when you press it. You can use an oscilloscope to see that. The bouncing is not as bad on release but I imagine it still exists there too.

Another fun hardware trick is that when you turn off a magnet (like a relay) you can get a massive over-voltage pulse back (10x typical drive) for a moment. You need to protect yourself from that, for instance with a Schottky diode. Here's a discussion on that fun detail [1].

[1] https://forum.allaboutcircuits.com/threads/reduce-voltage-sp...

Of course. Hardware debouncing came long before software. It's basic electronics. Many switches have it built in.

>"The scrambling is easy to see once you know it's happening: press k and l simultaneously on your Thinkpad keyboard. It'll always come out "lk" unless you deliberately separate them."

Is there an easy way to fix this? This is a noticeable nuisance in Emacs, when chord strings get "debounced" out of order (i.e. things like C-xC-m -> C-mC-x are quite annoying). The debounce precision is slower than fast human typing. Even though keypress event order is correct and noticeably correct, it gets rounded to "simultaneous", and then reordered (backwards) according to the logic you've described.

I’m always noticing the terrible denouncing times on things like appliances or garage doors, but I never thought about how it affects multiple key presses in keyboards. Fascinating to get more insight into a particular pet peeve of mine.

This must be it, then. The key pairs / triplets that I type in most quickly are left to right.