Testing was done [0], but it's not written in an easy-to-understand way. As a summary, Thinkpad keys are scrambled within 15-23 ms. Usually, humans ascribe scrambled letters to their own mistakes, but this time it's the keyboard's fault. Lenovo continues to ignore the issue.
One very stupid solution for your password is to change its letters to go from right to left. That way the scrambling will become anti-scrambling and you can type your password even faster than on a normal keyboard!
But if you want to reduce hardware cost, you can eliminate many capacitors and resistors by doing it in firmware instead.
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...
That shit adds up. BOM costs are everything for consumer goods.
I don't want to encourage shitty design for pennies at any level.
Stop making shitty shit.
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.
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.
In fact it's more customizable for quicker response than hardware RC debouncing.
There is, however, something wrong with shitty debouncing software.
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...
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.
On top of that, I didn’t know what the issue was and it drove me nuts until I figured it out. Left a very bad taste in my mouth for Lenovo/ThinkPad despite all the love they receive.