-
Peter Hutterer authored
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>
576f2ed2