EVEMU-DESCRIBE(1)

💖 EVEMU-DESCRIBE 💖

okay bestie, we're doing evemu-describe(1) today — and yeah, evemu-record is in here too, they're basically twins, they share a page. this is section 1 of the manual, so it's a user command situation. sit down, grab a strawberry 🍓, we're gonna read the input device's whole diary together.

---

✨ NAME ✨

evemu-describe, evemu-record — print information and events from an input device 💅

---

🌸 SYNOPSIS 🌸

evemu-describe [/dev/input/eventX] [output file]

evemu-record [--autorestart=s] [/dev/input/eventX] [output file]

---

🦋 DESCRIPTION 🦋

So. evemu-describe goes and gathers all the info about an input device, and then prints it to stdout. it's literally collecting the device's whole lore. and the glow-up? that info can be parsed by evemu-device(1) so you can build a virtual input device with the exact same properties. no cap. 👑

Meanwhile evemu-record captures events from the input device and prints them to stdout. those events can be parsed by evemu-play(1) so a virtual input device made with evemu-device(1) can emit the exact same event sequence. it's giving perfect recall. iconic behavior honestly.

🫶 Heads up: both evemu-describe and evemu-record need to be able to read from the device. in most cases that means they must be run as root. yeah. root. the whole vibe check is privileged. 😭

If you hand them an event node, evemu-describe and evemu-record use that event node. if you don't? then you have to interactively choose from a list of detected devices. very choose-your-own-adventure of you.

And if no output file is given, stdout is used. default behavior, slay.

---

✨ OPTIONS ✨

• --autorestart=<s> — terminates the current recording after <s> seconds of device inactivity. ⏰ this one requires an output, and the file gets suffixed with the date and time of the recording's start. also: the timeout must be greater than 0, so don't try to be cute with a zero, it's not gonna fly bestie. 🚫

---

💀 DIAGNOSTICS 💀

okay so this is the part where things get mysterious. if evtest-record doesn't see any events even though the device is clearly being used, then the device may be grabbed by a process (EVIOCGRAB). rude of that process, honestly.

this is usually the case when you're debugging a synaptics or wacom device from within X. the way that X just... holds onto your device. 🙈

the fix? VT switching to a TTY, or shutting down the X server — either one terminates this grab and then the devices can be recorded. 🎀 and for most X drivers, disabling the device also removes the grab. two paths, both work, pick your fighter.

here's the command that shows you the processes with an open file descriptor on the device:

fuser -v /dev/input/eventX

run it, find the culprit, live your truth. 🔥

---

🌈 SEE ALSO 🌈

evemu-device(1) evemu-play(1)

---

👑 AUTHOR 👑

evemu was written by Henrik Rydberg <rydberg@euromail.se[1]> 💜

---

📝 NOTES 📝

1. rydberg@euromail.se mailto:rydberg@euromail.se

---

and that's the whole page, bestie!! 🧚 this little gem is from 09/25/2017, and it lives under the name EVEMU-DESCRIBE(1). now go describe some devices, you main character. ⭐💖