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


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


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.

  • Can you post the output of xev when that happens? Does it also happen at the linux virtual console? It sounds more like a VirtualBox issue (which provides with the virtual keyboard) than a hardware issue. Do you have the problem with other Windows applications as well? Commented Oct 2, 2015 at 14:32
  • Thanks for the suggestion @StéphaneChazelas, I booted knoppix and ran xev to confirm the issue. Commented Oct 4, 2015 at 19:43

1 Answer 1


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.

  • 1
    Thanks Dmitry. It turns out a BIOS update solve my problem, but I'm accepting your answer because its what I would have tried next had there not been a BIOS update. Commented Oct 4, 2015 at 20:12

You must log in to answer this question.

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