Only the ones we care about in libinput but for those it's handy to know which
ones are set (especially the LIBINPUT_MODEL ones).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
