Similar in style to evemu-play but parses the YAML printed by
libinput-record. Note that this tool requires python-libevdev which is a new
package and may not be packaged by your distribution. Install with pip3 or
alternatively, just ignore libinput-replay, it's a developer tool only anyway.
User-visible differences to evemu-play:
* supports replaying multiple devices at the same time.
* no replaying on a specific device, we can add this if we ever need it
* --verbose prints the event to stdout as we are replaying them. This is
particularly useful on long recordings - once the bug occurs we can ctrl+c
and match up the last few lines with the recordings file. This allows us to
e.g. drop the rest of the file.
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>
Missing '+' in the optstring caused it to evaluate all options. If any
argument was passed to a subcommand, libinput-measure would throw an error and
exit.
https://bugs.freedesktop.org/show_bug.cgi?id=105246
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tweak this python scripts to use '/usr/bin/env python3'
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since the install script cannot know the correct bindir, just pass it
from Meson directly.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A lot easier to process data in python than in C.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Dima Ryazanov <dima@gmail.com>
Tested-By: Dima Ryazanov <dima@gmail.com>
Bluetooth wreaks havoc with the timestamp of the input events coming
from the touchpad, enable timestamp smoothing support to counter this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Switch to a pure factor with a max scaled after a function. The offset is just
0 now (will be removed eventually). Both are determined with a function based
on a linear/exponential regression of a sample set of data pairs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Trackpoints can send very different ranges between the various pressures.
Collect the data and print it out to get an idea of what ranges are realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no guarantee that libinput does the right thing if memory allocation
fails and it's such a niche case on the systems we're targeting that it just
doesn't matter. Simply abort if zalloc ever fails.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Uninitialized variables, potential NULL dereferences, dead assignments and an
unused return value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's switch to PEP8-compatible format to have a consistent style that matches
other python sources. This will be checked by flake8 which shows a few other
warnings, this patch only changes tabs to 4 spaces.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And update the documentation for how to use the new tool. It's much more
interactive than evemu and easier to grasp, so let's advertise that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make the libinput page more generic but suitable for short attention spans and
most importantly, point to the xf86-input-libinput man page in a more obvious
manner since we're now shadowing that.
The rest of the man pages have punctuation and formatting cleanups only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We had one shared parsing function for all config options so tools parse
options that don't actually make sense (e.g. --quiet or --show-keycodes for
libinput-list-devices).
This patch splits the actual libinput device configuration out and reshuffles
everything to make use of that. One large patch, because splitting this up is
more confusing than dumping it all.
This means the actual option parsing is partially duplicated between debug-gui
and debug-events but hey, not everything in life is perfect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The full information is now in the man page, the usage() now just tells you
how to use it. This way there's only one place to maintain it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
