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 useful.


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 mydevice.desc.
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

Grabbed devices

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 with

            xinput set-prop "my device name" "Device Enabled" 0

Getting evemu

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

  1. 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.
  2. Pipe the evemu-describe and evemu-record information into a file.
  3. Verify that both files contain data, a 0-byte file usually indicates the device is grabbed.
  4. 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 report.
  5. Attach both files separately, do not zip them as a tarball
https://wiki.ubuntu.com/Multitouch/Testing/Evemu has further information and instructions on how to use evemu.