<p> The user space interface of evdev is pretty generic. All hardware abstraction is done in the kernel driver, device properties are mapped to a set of generic properties. The properties can be queried thru a generic interface only very few parameters are set from user space. In user space the evdev API is used by Xorg's evdev driver and libinput. </p> <p> Debugging issues these drivers have with certain kinds of input devices requires to have access to the hardware. This is often not the case: <ul> <li>When the customer reports an issue with a specific device to support this device is often not available for testing.</li> <li>When a fix to the driver is made for a specific device the issue cannot reproduced by QA due to the lack of hardware</li> </ul> It would therefore be useful to have a way to record device properties and data. This data can later on be replayed thru an emulated driver. To user space this driver presents the same properties as the driver for the real hardware. Capturing and replaying in 'real time' should be easy as evdev events contain precise time stamps. </p> <p> Three pieces are needed: <ol> <li>an application to capture events in user space</li> <li>a kernel driver providing an API to user space to add device properties and send event data for replay</li> <li>an application for replay. This application should be capable of pausing and restarting the replay at any frame inside the stream</li> </ol> </p> <p> There is <a href= http://cgit.freedesktop.org/evtest> evtest</a> already, a tool to read out the device capabilities and properties and the stream of events. This tool can serve as a starting point of a capturing/recording application. </p> <p>Once this application is in place a replaying kernel driver can be created. This driver has to be able to take a bunch of device properties, emulate a device with these properties and trigger an uevent indicating to the client side that such an device has appeared. It has to be able to satisfy read requests from user space for device properties and capabilities. When it instructed it has to send a series of event with accurate timings. Fortunately evdev doesn't use many client requests that change the driver state. Basically there are requests to <ul> <li> set a key code</il> <li> set absolute values and limits</li> <li> set the clock ID for time stams</li> <li> set repeat settings</li> <li> set and cancel forced feedback effects</li> </ul> While key code and absolute values and mappings can be handled by remapping a key code / recalculate a valuator, the clock ID request can be handled just normally, while repeat settings need to be ignored like obviously requests for feedback effects as these don't make sense without a physical device. </p> <p> As the last piece the application doing the replay needs to be created. </p>
This project is one of its kind!