Use the evtest utility to record raw input events from Linux or BSD systems without capturing video. This tool reads directly from the kernel’s event interface, logging keystrokes and mouse movements to a file for debugging purposes. It requires no screen recording overhead and provides precise data on input device states.
Understanding Input Event Recording
When you press a key or move a mouse, the operating system translates these physical actions into digital signals. In Linux and BSD systems, this translation happens at the kernel level before any graphical application ever sees the data. Standard screen recording software captures pixels, which is inefficient if you only need to analyze the input sequence itself. Instead, we target the input subsystem directly.
The primary method for accessing this low-level data involves reading from specific device nodes in the /dev/input/ directory. These nodes represent physical devices like keyboards, mice, and touchpads. By monitoring these nodes, you can capture every event generated by your peripherals. This approach is particularly useful for diagnosing hardware faults, testing automation scripts, or analyzing user interaction patterns without the bloat of video metadata.
It is important to distinguish between recording input and recording screen activity. Tools that simulate input, such as xdotool, are designed to generate events, not log them. Similarly, network monitors like portmon track network traffic, not peripheral I/O. To get accurate input logs, you must use utilities specifically built to parse the Linux input event stream.
Installing Required Utilities
The most reliable tool for this task on modern Linux distributions is evtest. This utility is part of the evdev suite and is widely available in major package repositories. It allows users to select an input device and print all subsequent events to the standard output.
- Debian/Ubuntu: Install the package using
sudo apt install evtest. - Arch Linux: Use
sudo pacman -S evtest. - Fedora: Run
sudo dnf install evtest. - FreeBSD: The equivalent functionality is often found in
sysutils/evdevor viakldloadmodules, though native support varies more than in Linux. On FreeBSD, you may need to load theuhidmodule first.
If you are running a minimal system or a specialized embedded environment, ensure that the evdev kernel modules are loaded. Without these modules, the system will not expose the necessary device nodes for evtest to read. You can verify module availability by checking the output of dmesg | grep evdev or consulting your distribution’s documentation on input subsystem configuration.
Running the Recorder Safely
Accessing input devices requires elevated privileges because these devices are typically owned by the root user or the input group. You cannot simply run evtest as a standard user and expect it to work. Refer to our guide on Run Programs with Elevated Privileges: A Comprehensive Guide to understand the security implications of using sudo versus adding your user to the input group.
- Open a terminal window on the target machine.
- Execute
sudo evtest. This command lists all available input devices detected by the kernel. - Select the device ID corresponding to your keyboard or mouse. Be careful not to select virtual devices like "Virtual Console" unless you intend to test console input.
- Once selected,
evtestwill begin printing events. Every key press, release, and mouse movement appears in real-time. - To save this output, redirect it to a file using shell redirection:
sudo evtest > input_log.txt.
This process creates a text file containing timestamped events. Each line includes the type of event (e.g., key, relative motion), the code associated with the action, and the value. For example, a key press might appear as Event: time ... KEY_A (94) Press. This format is machine-readable and easy to parse with scripts.
Interpreting the Output
The raw output from evtest can look dense, but it follows a consistent structure. Understanding this structure helps you filter noise from significant actions. The first column indicates the event type, which determines how the second and third columns should be interpreted.
- Key Events: Type 1. Code 94 usually maps to 'A' on a QWERTY layout. Value 1 means pressed, 0 means released.
- Relative Motion: Type 2. Used for mouse X and Y axes. Positive values move right/down, negative moves left/up.
- Synthetic Events: Type 0. These mark the end of a frame and include timestamps. They are crucial for calculating latency between actions.
If you find the raw codes confusing, consider using evemu-record, another tool in the suite that can replay recorded events. This allows you to verify that your recording logic is sound by reproducing the exact sequence later. However, for simple logging, evtest remains the most straightforward option.
Troubleshooting Common Issues
Users often encounter permission errors or missing devices when attempting to record input. If evtest reports "No such device," ensure that the correct kernel modules are loaded. On some systems, USB devices may require a moment to initialize after boot. Restarting the service or replugging the device can resolve transient connection issues.
Another common problem is capturing too much data. Virtual devices, such as those representing touchscreen gestures or multi-touch pads, can generate thousands of events per minute. To avoid cluttering your log file, try to identify and exclude virtual input sources. Focus on physical HID (Human Interface Device) peripherals for cleaner data.
For persistent issues with device access, check the ownership of files in /dev/input/. Your user account needs read permissions on these nodes. Adding your user to the input group is a permanent fix that avoids the need for sudo every time you start a recording session. See Fixing "Permission denied» with OpenSSH: Manually adding authorized_keys for similar concepts regarding manual permission management.
Frequently Asked Questions
Can I record input on macOS using these tools?
No, evtest and the Linux input subsystem are specific to Unix-like kernels that implement the evdev interface. macOS uses a completely different driver architecture called IOHIDManager. You would need to use AppleScript or Python libraries designed for macOS accessibility APIs instead.
Does evtest capture audio input?
No, evtest exclusively handles Human Interface Devices like keyboards, mice, and game controllers. Audio input is managed by the ALSA or PulseAudio subsystems, which require different tools like arecord or parec for capture.
Is it safe to leave evtest running in the background?
Yes, it is safe, but it consumes disk space as it writes to the log file. Since it does not interact with the graphical interface, it will not slow down your computer significantly. Just ensure you have enough storage for long recording sessions.
How do I stop the recording process?
You can stop evtest by pressing Ctrl+C in the terminal where it is running. If you redirected output to a file, the file will remain intact with all data captured up to that point.
Can I replay the recorded events automatically?
While evtest only records, the companion tool evemu-record can create replayable scripts. You can then use evemu-play to inject those events back into the system, effectively automating the recorded actions.