Fix keyboard chattering/bouncing on the software side
In X11 on the software side, you'll want to adjust the bounce key delay xkbsetbouncekeysdelay
http://linux.die.net/man/3/xkbsetbouncekeysdelay
And, as with any mechanical keyboard, a good cleaning may be in order.
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.
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>