9 ms·

I checked the keyboard debouncing logic [0] and it was fine. Some keyboards from other manufacturers, notably Lenovo Thinkpads, have absurd debouncing algorithm

• poyu 5y ago
  Debounce is an interesting topic[0], I tend to use hardware debounce whenever possible on my own projects. [0]: https://hackaday.com/2010/11/09/debounce-code-one-post-to-rule-them-all/ https://hackaday.com/2010/11/09/debounce-code-one-post-to-ru...
  • CamperBob2 5y ago
    Don't accept a keypress if the same key was previously pressed less than x milliseconds ago. What else is there to know about debouncing?
    • talideon 5y ago
      The problem is that you're dealing with an analogue signal. The gold standard for debouncing because of that is a low-pass filter, which is implementable by a resistor and capacitor, and way more reliable (and responsive) than any software solution.
      • CamperBob2 5y ago
        Can you describe a case in which rejecting a duplicate keypress that arrives within a specified number of milliseconds is ineffective, unreliable, or even suboptimal? A lowpass filter is an empirical hack, not a gold standard. It has multiple disadvantages; rather than being "responsive," it adds latency to the initial input for no good reason, and it affects both rising and falling edges equally, again for no good reason. It also requires the addition of unnecessary physical components.
    • sydthrowaway 5y ago
      What is x? Is it related to human capability?
      • CamperBob2 5y ago
        Key bounce takes place at timescales far shorter than human reaction times. Typically you'd base the interval on the mechanical characteristics of the keypad. For instance, taking a look with a scope, if you observe that the signal stops bouncing after 3 milliseconds, it would be pretty safe to accept duplicate keypresses with a 10-ms guard interval.
        • alar44 5y ago
          You'd have to have two intervals though, one for on, one for off. It bounces both ways. Hardware is more elegant but obviously the tradeoffs depend on what you're implementing.
          • CamperBob2 5y ago
            It bounces both ways but as long as you don't accept another keypress action (up or down) immediately after the first, you're fine.
            • alar44 5y ago
              You're fine either way. You either have to poll, or use interrupts. If you are polling, you don't need to debounce the circuit. If you use interrupts, you're going to have a very bad time if you don't. Interrupts are much more efficient. Polling is wasteful.
              • brokenmachine 5y ago
                I don't see why interrupts wouldn't work without hardware debouncing. $2 micros are many MHz. All it has to do is save/compare one timestamp per interrupt. So lets do some back-of-the-napkin calculations and say it takes 1us to store/compare the timestamp, a switch transitions 50 times per press on each change of state, and a person is typing at 100wpm (lets say 600cpm = 10cps). I think these are pretty conservative numbers, 50 bounces sounds like a pretty crappy switch to me. So 1000 transitions per second which would take 1ms, which means 1/1000th of the time is spent servicing the interrupts. It's not going to cause a problem unless the coding is very inefficient.
  • auxym 5y ago
    There's some good info here if anyone is interested: http://www.ganssle.com/debouncing.htm http://www.ganssle.com/debouncing.htm
• nrp 5y ago
  We used the chromium-ec logic as-is (checking git blame), but I believe did tune the debounce timer to match the characteristics of the keyboard itself.
• ohazi 5y ago
  I've noticed that I seem to miskey my unlock password immediately after resuming from sleep way more often than when I use that password at other times, or when using an external keyboard (Lenovo T480). I always suspected that something was wonky, but a weird debounce bug would totally explain it, especially as I tend to type that password very quickly.
  • ad8e 5y ago
    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. 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! [0]: https://github.com/ad8e/input-polling-test https://github.com/ad8e/input-polling-test
    • stavros 5y ago
      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.
      • OneLeggedCat 5y ago
        Wow. All these years it's been the keyboard, not me. Kinda mildly infuriating.
        • stavros 5y ago
          Yeah, it really is, and people didn't believe me when I said with certainty that it was the keyboard's fault.
• Teknoman117 5y ago
  Out of curiosity, is there anything in particular that you're looking for? On a cursory glance, whenever a key state is sampled as different to the previously reported state, it immediately reports a state change and locks out any further reports for a specified amount of time. So, the report goes out the moment the state changes, so long as you can't perceive the debounce time, which I presume would be a few dozen microseconds. (Rather than some debouncers I've seen which wait for the debounce period to end before sending the initial report)
  • fps-hero 5y ago
    Yes. Essentially, when you see an edge, update the state immediately but have a guard interval before allowing further state changes. Intuitively, this means register the event when you see the first edge, not once the bounces have finished. For an example of incorrect denouncing, see most articles on denouncing (the hackaday article comes to mind), and the QMK firmware last time I checked (most keyboard set the denounce time to zero, so the debounce time just becomes the update rate).
    • colejohnson66 5y ago
      > Yes. Essentially, when you see an edge, update the state immediately but have a guard interval before allowing further state changes. Isn’t that ultimately what capacitor + Schmitt buffer debouncers does? The only difference is that this would be in software?
      • fps-hero 5y ago
        A capacitor plus pull up resistor will add an RC time constant delay on switch release, and for it to be effective at denouncing it needs to be on the order of 10ms. A software solution has zero delay in both cases. A Schmitt buffer isn’t necessary when using polled GPIO with a microcontroller. An equivalent accurate discrete logic circuit would be a latching circuit with a gated input pulse on state change corresponding to the denounce time, which is overkill for simple button handling.
• google234123 5y ago
  The copyright header at the top says "chromium".
  • deleted 5y ago
    [deleted]
• lukeschlather 5y ago
  This reminds me of a weird issue I have with my Lenovo where sometimes the trackpoint and mouse buttons stop working until a reboot (but the trackpad still works.) I think I must trigger a race condition in the trackpoint drivers somehow but I have no idea how to debug it.
  • namibj 5y ago
    I remember such an issue; unloading and reloading the kernel module fixed it.
    • lukeschlather 5y ago
      This is on Windows, I haven't tried installing Linux on the machine. It's also intermittent enough that it's virtually impossible to debug.
• bsder 5y ago
  I find the has_ghosting() function more problematic and reminds me of why C just sucks even if it is the appropriate choice. c and c2 loop variables so a typo can hose you horribly. A global variable to hold the array length. ! instead of comparison to 0. Having to offset the second loop by 1. Early return which means the function will normally work fine but might result in N^2 extra time depending upon the data state. A bit trick relying on unsigned underflow without pointing out that unsigned is a key constraint even though it has a comment. An extra missing const on the incoming pointer (should be: const uint8_t * const). Braces left off the short-circuit if conditionals. The worst part is I have personally written tons of functions like this. This is a "normal" function in C--in fact, it's far better than average. The fact that you write C like this just shows how much we need something better.
  • account42 5y ago
    > A global variable to hold the array length. This is a microcontroller firmware. Moving what is essentially a constant around the stack would be insanity. > ! instead of comparison to 0 Not a problem and even idiomatic. > Early return which means the function will normally work fine but might result in N^2 extra time depending upon the data state. It only takes N^2 time when all columns have at least one key pressed but not have at least two rows in common in any of them (except maybe the last two) - hardly a state that you care that much about. Would you really want to increase the latency/power consumption for single key presses just to have the exceptional case not be slower than normal? If you wanted to you could restrict the early exit with the same test for having at least two bits set. If the key matrix has no unused slots you would then only check if there is another column which shares any set row bits (because it would then share all of them), which could let you make the algorithm O(n) with some additional memory for row bit counts. But the code would be more complicated and the number of columns is not dymanic. Plus the key matrix most likely has unused slots precisely to avoid ghosting for common combinations. > A bit trick relying on unsigned underflow without pointing out that unsigned is a key constraint even though it has a comment. The variable with type is declared right before the bit trick. If you change it to signed when there are bit operations, especially ones you don't understand, then you deserve what you get. However, this trick does not rely on unsigned underflow. the only concern with signed (assuming two's complement) would be if the sign bit is the only one set, in which case the signed underflow would be undefined at the language level - but not a problem at the hardware level since two's complement addition/subtraction is exactly the same as unsigned addition/subtraction. > An extra missing const on the incoming pointer (should be: const uint8_t * const). const on the outside of function parameter types (as opposed to inside them) does not change how the function can be called. Sure, you could make all local variables const if they can be but for such a tiny function that really does not add anything. > Braces left off the short-circuit if conditionals. Meh, that is a code style choice and no reason to complain about C. Also not really that dangerous with modern compilers that warn based on misleading indentation. And you missed the actually bad part of the function: The comment that says the colummns are ORed together when they are ANDed.
• baybal2 5y ago
  I want to produce a keyboard switch which needs no debounce.
  • lwhsiao 5y ago
    This appears to be the goal of optical switches.
  • ChuckNorris89 5y ago
    IIRC those already exist in the form of optical switches.
    • baybal2 5y ago
      Yes, but they are overengineering a simple problem. A mechanical bounce free switch is a no problem at all.
      • ChuckNorris89 5y ago
        >A mechanical bounce free switch is a no problem at all. Two questions: 1) do mechanical switches with zero bounce really exist? 2) are they cost effective enough to be used in consumer keyboards?
        • baybal2 5y ago
          > 1) do mechanical switches with zero bounce really exist? You just use a switch with 2 outputs: for on, and off position. Triggering 2 at the same time is impossible. > 2) are they cost effective enough to be used in consumer keyboards? Surely less than a percentage of a cent in extra cost.
          • ChuckNorris89 5y ago
            >You just use a switch with 2 outputs: for on, and off position. Triggering 2 at the same time is impossible. But then the switch will still bounce except now it bounces with an extra state and you need extra logic to read an extra output per switch and debounce both outputs, which also makes PCB's more complex further increasing the cost. >Surely less than a percentage of a cent in extra cost. With the extra PCB and custom logic complexity you just added with the extra output per switch, you're looking at way more than that, which I guess is why the industry went optical instead of following your idea.
• belfalas 5y ago
  This made me wonder if debouncing is also a thing with software keyboards? For years I have sworn that I type things correctly on the iPhone keyboard but it gets it wrong.
  • brokenmachine 5y ago
    I'd assume that the capacitive touch sensing will certainly have some kind of debouncing as it crosses whatever the threshold is to register a touch or not.