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.
3
4 Answers
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.
-
4A search for
keymonofkey-moncurrently returns no results from the Universe. You might need to expand your answer. Commented Apr 29, 2021 at 13:19 -
-
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
evtestin grabbing mode on my keyboard's device file (replace it with yours). evtestis run with a timeout of 10 seconds, and additional grace period of 5 seconds in (unlikely) case it hangs, after which it's killed bySIGKILL, hopefully returning keyboard control to you.sudois wrapped around the whole command instead of onlyevtestto make sure that you enter the password (if needed) beforesleep 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.
-
Wouldn't it be better to do
sudo sleep 1to prevent the password issue? Commented Dec 23, 2019 at 3:35 -
1@OctaviaTogami indeed; I've edited the answer with an even simpler approach.– RuslanCommented Dec 23, 2019 at 6:39
-
Install with
sudo apt update && sudo apt install evtest. Commented Dec 20, 2021 at 16:51 -
Upvoted. This works great! See also the
sudo showkeyanswer here, and my comment underneath it with a summary here. Commented Dec 20, 2021 at 17:04 -
1@GabrielStaples
showkeyis higher-level thanevtest. It works with/dev/consoleinstead of the actual keyboard. Thus, not only can'tshowkeyintercept 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.– RuslanCommented Dec 20, 2021 at 17: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.
answered Dec 23, 2019 at 8:15
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
answered Dec 21, 2019 at 8:57
-
1The site shows me a QWERTY keyboard, while I use an AZERTY one.– xenoidCommented Dec 21, 2019 at 12:04
-
And it's broken for my en-gb QWERTY. Zero effort has gone into localisation there. Commented Dec 21, 2019 at 20:12
xevwould be what I'd use