Create evdev Event Recorder & Playback Driver
a project by eeich
Updated over 5 years ago. 1 hackers ♥️.

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.

Debugging issues these drivers have with certain kinds of input devices requires to have access to the hardware. This is often not the case:

  • When the customer reports an issue with a specific device to support this device is often not available for testing.
  • When a fix to the driver is made for a specific device the issue cannot reproduced by QA due to the lack of hardware
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.

Three pieces are needed:

  1. an application to capture events in user space
  2. a kernel driver providing an API to user space to add device properties and send event data for replay
  3. an application for replay. This application should be capable of pausing and restarting the replay at any frame inside the stream

There is evtest 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.

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

  • set a key code
  • set absolute values and limits
  • set the clock ID for time stams
  • set repeat settings
  • set and cancel forced feedback effects
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.

As the last piece the application doing the replay needs to be created.

Join this project

Looking for hackers with the skills:

Nothing? Add some keywords!

This project is part of:

Hack Week 12

Activity

  • over 9 years ago: srett liked this project.
  • over 9 years ago: srett started this project.
  • over 9 years ago: eeich originated this project.


    • Comments

    • srett
      over 9 years ago by srett | Reply

      I'll give this a try. Some random thoughts:

      Considering the options we have for the file format (xml/json, plain text, binary), my conclusion is to use a binary format. The data being dumped will actually be just an endless stream of the input_event struct (plus a file header). This has the downside that the byte order of the fields, and possibly the size/number of fields might differ between machines with different architecture or system versions.

      There are however two advantages I see:

      • We pretty much get the raw data as seen on the machine the data was recorded on. This might help in cases where unexplained behavior is observed, without any mangling of the data that might potentially hide issues.
      • As much processing of the data is pushed to the analyzing tool. This keeps the modifications to evtest minimal, which should increase the odds of getting the recording feature merged into evtest eventually, meaning we have to maintain only the playback driver+util.

      Any feedback is very much appreciated.

    • srett
      over 9 years ago by srett | Reply

      Aight, so the first version of evrec is working. After I had an early poc running on Tuesday I realized that there are potentially much more properties a device has than what evtest queries and displays, so I eventually forked off evtest to create evrec.

      Unfortunately I could not really find detailed information on all the bits and pieces that you can query from an input device, also I was not sure how much I can rely on EVVERSION guaranteeing that all involved data sctructures would be the same for a specific version, of if EVVERSION just really marks the protocol version (and thus only struct input_event).

      So I over-carefully put lots of information into the header in order to be able to check if everything is as you'd expect it when playing a recorded input sequence back. Figured we can still just ignore these fields later if they turn out not to be necessary.

      Anyways, git repo is up at https://github.com/srett/evreplay -- documentation still lacking mostly.

    Similar Projects

    This project is one of its kind!