Linux – Working around a buggy keyboard / hacking an input stream

inputkeyboardlinux

When I type the key sequence oun quickly, the key sequence oun<F12> is emitted by my keyboard.

(Update: actually, you must press-and-hold each key in the sequence in order to trigger the problem. If the 'o' is released before pressing 'u', the problem does not trigger).

I first noticed the problem when typing into a website using Google Chrome, and noticed that the developer console would randomly pop up while typing. I didn't figure out the specifics until I was typing into vim and suddenly an <F12> appeared in my text.

A few minutes of experimentation yielded the following:

  • This is 100% reproducible, every time
  • It is triggered specifically by the key sequence "oun"
  • The first key must still be depressed by the time you hit the third key. Releasing each key before pressing the next does not trigger the problem (this is why you only encounter the problem when typing quickly).

As a developer, this seems like a straight-forward problem to solve (if you see these four inputs in sequence, drop the fourth). However, I have no idea where to start: what low-level input stream filtering is available on Linux, or how to go about hacking device drivers and such.

My question is, where would I implement a change like this? In the kernel? It there a keyboard input processing mechanism which accepts filters?

Additional details:

This is on an HP ProBook 4530s (a business laptop from 2011). I'm running Debian 8 in a VirtualBox VM on a Windows 7 host. I haven't yet booted into Knoppix to verify the problem still exists in a 100% pure Linux environment, but I'm pretty confident this is problem is happening below the level of the OS.

Someone else reported the exact same problem (the same sequence of keys) back in 2012 with a brand new 4530s: http://www.tomsguide.com/forum/75276-35-keys-activate-typing-help

UPDATE:

I booted the 4530s using Knoppix and ran xev to confirm that this is a hardware issue. Here's an excerpt of the output, where you can see the oun<F12> sequence: https://gist.github.com/cellularmitosis/018d822e5ccc5c1a64e6

UPDATE 2:

Well, I got lucky and a BIOS update was sufficient to solve the problem. See http://h20564.www2.hp.com/hpsc/swd/public/detail?sp4ts.oid=5060881&swItemId=ob_146941_1&swEnvOid=4059

I'm accepting Dmitry's answer because that's what I would have tried next had the BIOS update not solved the problem.

Best Answer

There's a project on GitHub called inputty which does what you're trying to achieve - it reads evdev events from real HID devices and creates uinput devices to emulate virtual HID hardware. For example, here's a qml script adds a virtual keyboard which outputs an additional x keypress after an f keypress on a real keyboard.

You should be able to implement your algorithm with this, or just drop the F12 key if you can live without it.

Related Question