I have a mechanical keyboard (Noppoo Choc Mini with Cherry MX Blue switches) and after a few weeks, some key presses are getting sent two times even though I press a single time. I found out that this is a common problem on mechanical keyboards and is called 'chattering' (or 'bouncing').

This comes likely from a hair inside the mechanics of the switch, so my posssibilities are limited here:

  • Replace the switch manually (soldering, reordering single parts from beyond, ...)
  • Buy a new one
  • ... or fix it on the software side.

So my question: is there a simple (or complicated, I'll take it all) way to fix this? Is there a kernel-patch, keyboard driver option, smart tool or a hidden settings in X11 to prevent my OS from registering the same key in a very short period of time?

6 Answers 6


Ran into this problem on ubuntu 16 with an aging keyboard. Ubuntu has an option under system settings -> universal access -> typing. The option is called 'Bounce keys' with a description of 'ignores fast duplicate keypresses' and an option of 'acceptance delay' with a slider to regulate it. What I'm really trying to say is that Arch might have a similar accessibility setting and then in general that Operating Systems might have certain options under accessibility to help with this issue. This post https://bbs.archlinux.org/viewtopic.php?id=213835 got me thinking about that and basically solved my key chatter issue.

  • 3
    Nowadays, it's in the Accessibility section. But thanks, that was helpful.
    – GreenScape
    Commented Nov 26, 2020 at 9:26
  • 4
    On Ubuntu 18, Universal Access > Typing Assist > Bounce Keys. I used a much shorter delay than the default. Commented Dec 3, 2020 at 4:01
  • 1
    On Arch with GNOME 43.2, I found this under Settings > Accessibility > Typing Assist (AssistX) > Bounce Keys Commented Jan 27, 2023 at 21:53

Its not a common problem for mech keyboards, and the cherry MX switch was made to stop this problem, because of the way the switch works you have to come back off the contact past the latching point to make another contact its not like a 'dome board.

That said after many years of using most types of mech 'board without ever seeing a problem, I thought I would try a diff *nix distro (arch, I'm a slackware user) on a spare box, as soon as I hit the cli I started to get multiple key presses.

I checked it with another Filco, no change, and then an older ALPS blue switched, then an g80-3000 board with diodes, but nothing stopped it until I changed the BIOS kbrd speed down to normal, it was a problem for all of the boards I used.

From what I have read the above bounce delay setting is often not perfect for cherry switched boards, but as I dont leave the cli I doubt it really matters to me, but might help other users.

It could be a controller problem, I dont use my Noshist's (Noppoos) as I call them, but I did get one of the first batch of the Filco Zero board a few years back and that had a problem with the direction and speed of scan rate so you got lots of transposition errors (like teh) and there is a trick you can do by pressing a credit card (or something like) down at a slight angle into 4 or 5 keys a few times into a basic text editor and checking the results are correct.

The main point of this post is to say that I have never seen a bad cherry switch that was not damaged by some outside force, most often spillage or force from something being dropped onto the board. I have some 30+ cherry switched boards (yeah, its not, er, cough, sniff a problem or anything man ;) going back to a 1984 g80-1000 that works as good as it was new, and never given more than a brush out with a clean paint brush every few months.

Something I have seen (in the last 5-6 years) as mech boards have moved into the realms of a fashion object, is that new users bash the keys too hard, if you do bottom out the keys it should hardly make a sound, and when you dont bottom out you will start to get the best from the board.

The blue switch is the best for a new user to learn with, never start with a red switch.

That said if you type less than a few 1000 words a day or are a gamer there is not really any point in getting a mech board. /ramble

May 02, The more I think about this, the more I seem to remember there being some talk that in the Noppoo T&C's or advert it was only guaranteed to work on windows boxes. They did some trick in the USB/controller to get past the 6KRO (6 key roll over) hard limit that USB has. So they could say it had full, or nKRO, which you only have over PS/2.

ISTR there were people using the Teensy USB to over come this fake USB thing. Might have just been random key press and no LEDs in Linux and *BSD, apple mac that had the bigger problems.

edit aug'16

I have found this setting in bash that stops the multi key press on the cli. It changes the repeat rate of your keys. This seems to often be set to

kbdrate -r 32 -d 250 

which is the fastest a PC can go.

I found using..

kbdrate -r 9 -d 500

Will even allow a keyboard with problems to work fine

kbdrate -r <chars-per-second> -d <repeat-delay>
  • I have found this setting in bash that stops the multi key press on the cli. It Changes the repeat rate of your keys. set to kbdrate -r 32 -d 250 which is the fastest a PC can go. I use.. kbdrate -r 9 -d 500 kbdrate -r <chars-per-second> -d <repeat-delay>
    – Lenny_Nero
    Commented Aug 18, 2016 at 14:33
  • Thank you very much for your answer! I try the kbdrate command a while, in hope the double keys are gone. For the nKRO problem I've using a USB->PS2 adapter for a few years now with no problems.
    – f00860
    Commented Oct 7, 2017 at 14:56

In X11 on the software side, you'll want to adjust the bounce key delay xkbsetbouncekeysdelay


And, as with any mechanical keyboard, a good cleaning may be in order.


A cleaner approach to software debouncing might be to use xkbset(1), a little utility that lets one set up keyboard debouncing under X11 regardless of DM and other installed software.

The program is invoked using a simple xset-like syntax. For example,

$ xkbset bo 50

enables key debouncing with a threshold of 50 ms (to set a time delay without actually enabling the feature, prepend a - to the bo).

By default, the debouncing feature gets automatically (and quietly) turned off by X after a 120-s inactivity timeout, which may be undesirable. That can be prevented with the following additional command:

$ xkbset exp =bo

For details, read xkbset h. The available documentation is not that great, as others have pointed out, but this tool obviates the need for writing a custom C program just to call stuff like XkbSetBounceKeysDelay(3). Other X keyboard extensions are also readily accessible via xkbset.


OS: ubuntu 16.04.6 Keyb: Corsair K65 RGB

These settings solved my problem:

gsettings set org.gnome.desktop.a11y.keyboard bouncekeys-enable true
gsettings set org.gnome.desktop.a11y.keyboard bouncekeys-delay 50

I have visited this thread some time ago searching for solutions, but wasn't really satisfied with the options.

The bounce keys do work, but there's a problem. If you set the delay to 100 ms, for example, and press the key every 99 ms, it's going to filter all of the keypresses. Forever.

This doesn't work well for our problem because it's not just you pressing the keys too fast. Your keyboard inserts presses even if you don't do that. So let's say you press the key twice with a 120 ms delay, but there's a chatter 30 ms after your first press. The bounce keys feature is just going to discard both the chatter and your second keypress because it thinks only 90 ms passed from the last one - which was just a chatter, and was blocked anyway!

Now, it's easy to come up with a strategy that fixes that, but bounce keys don't allow you to change anything. I have searched here on the network and found an idea that I have now implemented in a tool:


It basically uses libevdev to completely capture all keypresses, then emit them again after applying filters. It's not an elegant solution but it works better than bounce keys, and it's completely customizable.

The strategy I use is filtering presses where the KeyDown occurs too soon after a previous (non-filtered) KeyUp. I've been using the tool myself for about 2 months and it seems to work very well. It's not perfect, mind you, but I was able to type all this without it chattering a single time, for example.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .