Commit graph

101 commits

Author SHA1 Message Date
Peter Hutterer
576f2ed2a7 tools: add a libinput-record tool
This is a tool that does effectively the same job as evemu-record.
evemu has two disadvantages: its API is clunky and hard to extend even for
simple features. And it has a custom file format that requires special
processing but is difficult to extend and hard to write manually. e.g. the
bitmasks require keeping a line number state to know which bit an entry refers
to.

libinput-record records the same data but the output is YAML. That can be
processed easier and extended in the future without breaking the parsing. We
can (in the future) also interleave the evemu output with libinput's debug
output, thus having a single file where the events can be compared and
analysed without the need for replaying.  Likewise, we can easily annotate the
file with parsable bits of information without having to shove all that into a
comment (like version numbers of libinput, kernel, etc).

User-visible differences to evemu-record:
* the output file requires an explicit -o or --output-file argument
* no evemu-describe equivalent, if you just want the description simply cancel
  before any events are sent
* to see key codes, a --show-keycodes flag must be supplied, otherwise all
  'normal' keys end up as KEY_A. This protects against inadvertent information
  leakage
* supports a --multiple option to record multiple devices simultaneously. All
  recordings have the same time offset, it is thus possible to reproduce bugs
  that depend on the interaction of more than one device.

And to answer the question of: why a printf-approach to writing out yaml
instead of a library, it's simply that we want to be able to have real-time
output of the recording.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2018-03-01 11:50:46 +10:00