If you have been directed to this page, you most likely are
requested to submit data to debug an issue with your device. Please
read this short page carefully to ensure the data provided is
evemu is a tool to record information about and events from an input
device. The data recorded can be re-played on another host,
creating a virtual input device that looks identical to all
components but the kernel. It is thus ideally suited to input device
debugging. The evemu package provides several binaries:
- evemu-describe /dev/input/event0 > mydevice.desc
- Prints a description of the device specified into
- evemu-record /dev/input/event0 > mydevice.events
- Prints the list of events from the device into
mydevice.events until terminated by Ctrl + C
- evemu-device mydevice.desc
- Creates a virtual input device based on the description
created by evemu-describe and prints the device node.
- evemu-play /dev/input/event12 < mydevice.events
- Sends the events in mydevice.events through the given device
node, thus replaying them. mydevice.events must be generated by
evemu-record cannot see events while another process has an
EVIOCGRAB on the device. This is the case for the X.Org synaptics
and wacom drivers, you must disable the devices or VT-switch
away before running evtest to see events. Devices can be disabled
xinput set-prop "my device name" "Device Enabled" 0
Check your distribution's package list for the evemu package.
If it is not present, you can get the source from
Note that before version 1.0.10, evemu was called utouch-evemu. Your distribution may provide a utouch-evemu package, which is likely fine unless you need the most recent bits.
Submitting useful evemu recordings
has further information and instructions on how to use evemu.
- Find out the right device file by checking
/proc/bus/input/devices. The HANDLERS line tells you
which event device to record. e.g. H: Handlers=kbd event2
means you need to record /dev/input/event2.
- Pipe the evemu-describe and evemu-record information into a file.
- Verify that both files contain data, a 0-byte file usually
indicates the device is grabbed.
- When reproducing the event sequence that triggered the
bug, try to reproduce only the event sequence that
triggered the bug, no unrelated events.
Keep in mind that event sequences are are raw device
data. If specific pointer positioning on the target host is
required, this must be noted separately in the bug
- Attach both files separately, do not zip them as a tarball