22

I am looking for a tool that tells what keys (including Alt, Shift, Ctrl, etc) are pressed now. Need it to do a health-check on a possibly faulty keyboard.

Denis Kulagin
  • 379
  • 1
  • 3
  • 9

4 Answers4

14

Install keymon. It's in the Universe repository and run it using key-mon (not keymon!).

man keymon has this:

Keymon - Keyboard and mouse monitor window for GTK.

Do read man keymon for all the options available.

You should also right-click on it to check that the settings are appropriate for you.

And if you don't like the default location, drag it to a more suitable position on your screen.

An alternative is screenkey, also in the Universe repository. A feature of screenkey is that it's interface only when you type something and disappears after a few seconds if the keyboard is inactive. However, unlike keymon, screenkey doesn't register mouse clicks.

There's a YouTube video on both keymon and screenkey. The video's in German but still is easy to follow.

DK Bose
  • 42,548
  • 23
  • 127
  • 221
13

To test a possibly faulty keyboard it's best to go as low-level as possible. One of the easiest ways to do this without diving into kernel space is to work almost directly with /dev/input/event* device files. Namely, you can use evtest to see all the keyboard input. If you run it in grabbing mode, this will let you intercept everything—even Magic SysRq combos (funnily, even SAK)!

Here's how I'd go about it. First, get a list of input devices by running sudo evtest:

$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      Power Button
/dev/input/event1:      Power Button
/dev/input/event2:      PC Speaker
/dev/input/event3:      Video Bus
/dev/input/event4:      HDA Intel HDMI HDMI/DP,pcm=3
/dev/input/event5:      HDA Intel HDMI HDMI/DP,pcm=7
/dev/input/event6:      HDA Intel HDMI HDMI/DP,pcm=8
/dev/input/event7:      HDA Intel HDMI HDMI/DP,pcm=9
/dev/input/event8:      HDA Intel HDMI HDMI/DP,pcm=10
/dev/input/event9:      HDA Intel PCH Front Mic
/dev/input/event10:     HDA Intel PCH Rear Mic
/dev/input/event11:     HDA Intel PCH Line
/dev/input/event12:     HDA Intel PCH Line Out
/dev/input/event13:     HDA Intel PCH Front Headphone
/dev/input/event14:     HDA NVidia HDMI/DP,pcm=3
/dev/input/event15:     HDA NVidia HDMI/DP,pcm=7
/dev/input/event16:     HDA NVidia HDMI/DP,pcm=8
/dev/input/event17:     ImExPS/2 Generic Explorer Mouse
/dev/input/event18:     AT Translated Set 2 keyboard
Select the device event number [0-18]:

Don't choose anything here yet: just press Ctrl+C. This run of evtest was in a simple non-grabbing mode, which won't let you intercept everything. But you now know the device file you need (in my case given above, it's /dev/input/event18).

Now you can actually run evtest in grabbing mode, using the --grab option, so that it intercepts all events from the keyboard—including the release of Return after you submit your command to the shell, subsequent Ctrl+C, Magic SysRq, VT switch shortcuts etc.. To avoid being locked out of the system, we'll set up a timeout for evtest.

sudo su -c 'sleep 1; timeout -k5 10 evtest --grab /dev/input/event18'

This command does the following:

  • Waits 1 second so that you can release Return before the keyboard is grabbed (otherwise you'll get autorepeats rapidly scrolling the console)
  • Starts evtest in grabbing mode on my keyboard's device file (replace it with yours).
  • evtest is run with a timeout of 10 seconds, and additional grace period of 5 seconds in (unlikely) case it hangs, after which it's killed by SIGKILL, hopefully returning keyboard control to you.
  • sudo is wrapped around the whole command instead of only evtest to make sure that you enter the password (if needed) before sleep 1, otherwise this sleep will be useless

During the timeout of 10 seconds (which you can, of course, change to something that suits you better) you can press anything on your keyboard—aside maybe from Fn-driven keys, which might work in a nonstandard way—and see what it inputs.

Ruslan
  • 1,733
  • Wouldn't it be better to do sudo sleep 1 to prevent the password issue? – Octavia Togami Dec 23 '19 at 03:35
  • 1
    @OctaviaTogami indeed; I've edited the answer with an even simpler approach. – Ruslan Dec 23 '19 at 06:39
  • Install with sudo apt update && sudo apt install evtest. – Gabriel Staples Dec 20 '21 at 16:51
  • Upvoted. This works great! See also the sudo showkey answer here, and my comment underneath it with a summary here. – Gabriel Staples Dec 20 '21 at 17:04
  • 1
    @GabrielStaples showkey is higher-level than evtest. It works with /dev/console instead of the actual keyboard. Thus, not only can't showkey intercept Magic-SysRq et al., it doesn't even let you choose the keyboard to check, instead accepting input from all keyboards attached to its console. – Ruslan Dec 20 '21 at 17:10
  • Instead of running sudo evtest once just to see which event number the keyboard is, you can obtain that path immediately, matching the word keyboard, like this: path_to_keyboard="/dev/input/$(cat /proc/bus/input/devices | grep -B 1 -A 10 -i keyboard | awk 'NR==6 {print $4}')". That allows you to run this: path_to_keyboard="/dev/input/$(cat /proc/bus/input/devices | grep -B 1 -A 10 -i keyboard | awk 'NR==6 {print $4}')"; sudo su -c "sleep 1; timeout -k5 10 evtest --grab $path_to_keyboard". – Gabriel Staples Dec 20 '21 at 21:51
  • @GabrielStaples there may be multiple keyboards, and some single multimedia keyboards have multiple HID presentations. My Logitech G213 Prodigy is an example. – Ruslan Dec 20 '21 at 21:53
  • @Ruslan, I see. I suppose you have to be very specific if trying to script something. Replace the grep for keyboard above with a grep for "AT Translated Set 2 keyboard", then it would work, no? – Gabriel Staples Dec 20 '21 at 21:55
  • @GabrielStaples first, the output in the answer was done when I had a PS/2 connection for the keyboard. This string will match it indeed. But now with USB connection I have two entries with the same name, Logitech Gaming Keyboard G213. Only one of them reports the normal keys like alphanumeric, functional etc. – Ruslan Dec 20 '21 at 22:00
  • Got it; makes sense. In case you're interested, I put a summary of my findings here, and referenced your answer. – Gabriel Staples Dec 20 '21 at 22:38
  • Works great! I tested this with two keyboards, and two keyboards can be identified. – Király István Oct 26 '22 at 17:38
  • Would have liked to try this, but evtest only listed 14 devices, and none are my keyboard. :) Oh well. Still a useful command to know. – odigity Jun 13 '23 at 16:29
  • @odigity this is odd. What X driver are you using for your keyboard? Does it use a device not from /dev/input/*? And what interface is the keyboard connected to? – Ruslan Jun 13 '23 at 17:12
  • @Rusian - I was just coming back here to delete my comment because I figured out that "Telink Wireless Receiver" was my keyboard. (model is X9 X9RFERGOKEY, amazon product B08G58HFTM - uses a wireless dongle) – odigity Jun 13 '23 at 17:39
10

xev is also an option. Install it, if it is not already installed, with:

sudo apt install xev

Then just run:

xev

Make sure that the small, white window that opens is selected and press any key to see details about it.

To limit xev's rather verbose output, so that it only shows the keys that you press, you can pass its output to awk:

xev | awk /keysym/'{sub(/\),/,""); print $7}'

In any case, note that xev registers two events for every key that you press, one for pressing the key and one for releasing it.

BeastOfCaerbannog
  • 14,585
9

There is a website https://www.keyboardtester.com/ which lets you see which keys you have pressed, and it shows the keyboard layout. Also, there is a package called xkeycaps which can be used. Moving the mouse over a key describes the keysyms and modifiers that that key generates

There are more sites available like

Pablo Bianchi
  • 15,657
Tejas Lotlikar
  • 2,945
  • 5
  • 17
  • 26