Using evemu to simulate input devices

I’m doing some experiments to make the remote controller of Parrot’s Disco drone (SkyController 2) to work with ArduPilot. I will talk more about this in another post. This one is basically about a nifty tool I’ve found that I didn’t know existed: evemu. I always used evtest to debug the input system in Linux.

SkyController 2 runs Linux and exposes all the sticks and buttons as an evdev device. I developed a tool to serve as a general-purpose software to be used in this kind of device: dema-rc. Ultimate goal is to have a software that can replace what comes on these controllers instead of parsing their packets like I did for 3DR SoloLink.

Testing it remotely on the target every time is time-consuming and requires me to leave both the drone and controller powered up. When I started it I thought about recording the events with evtest and then create a tool to expose that via uinput on my laptop. It turned out that tool already existed and it does in that exact way.

On SkyController 2 I run once:

$ evemu-record /dev/input/event0 skycontroller2.evemu

After copying that file to my laptop I can re-create a similar device locally by using:

$ sudo evemu-play skycontroller2.evemu
www.parrot.com MPP GAMEPAD: /dev/input/event23
Hit enter to start replaying

Then whenever I want the sequence of events to be re-played to test in my software I just hit enter on that window. You may want to use xinput to tell X to ignore that device, but in my case I didn’t need as it was already ignoring:

(II) config/udev: Adding input device www.parrot.com MPP GAMEPAD (/dev/input/event23)
(II) No input driver specified, ignoring this device.

This approach proved very useful as it worked on the remote device on the first try after debugging it with the replays.

blogroll

social