libinput/tools/libinput.man

72 lines
1.8 KiB
Groff
Raw Permalink Normal View History

.TH libinput "1" "" "libinput @LIBINPUT_VERSION@" "libinput Manual"
.SH NAME
libinput \- tool to interface with libinput
.SH SYNOPSIS
.B libinput [\-\-help|\-\-version] \fI<command>\fR \fI[<args>]\fR
.SH DESCRIPTION
.PP
libinput is a library to handle input devices and provides device
detection and input device event processing for most Wayland
compositors and the X.Org xf86-input-libinput driver.
.PP
The
.B "libinput"
tools are a set of tools to debug, interface with and analyze data for
libinput. These tools create libinput contexts separate from that of
the compositor/X server and cannot change settings in a running session.
See section
.B COMMANDS
for a list of available commands.
.PP
libinput's API documentation and details on features and various high-level
concepts are available online at
.I https://wayland.freedesktop.org/libinput/doc/latest/
.PP
The man page for the X.Org xf86-input-libinput driver is
.B libinput(4).
.SH OPTIONS
.TP 8
.B \-\-help
Print help and exit
.TP 8
.B \-\-version
Print the version and exit
.SH COMMANDS
.TP 8
.B libinput\-debug\-events(1)
Print all events as seen by libinput
.TP 8
.B libinput\-debug\-gui(1)
Show a GUI to visualize libinput's events
.TP 8
.B libinput\-debug\-tablet(1)
A commandline tool to debug tablet axis values
.TP 8
.B libinput\-list\-devices(1)
List all devices recognized by libinput
.TP 8
.B libinput\-measure(1)
Measure various properties of devices
.TP 8
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>
2017-11-23 11:01:45 +10:00
.B libinput\-record(1)
Record the events from a device
.TP 8
.B libinput\-replay(1)
Replay the events from a device
.TP 8
.B libinput\-analyze(1)
Analyze events from a device
.TP 8
.B libinput\-test(1)
Test libinput itself.
.SH LIBINPUT
Part of the
.B libinput(1)
suite
.PP
.SH SEE ALSO
libinput(4)
.PP
libinput's online documentation
.I https://wayland.freedesktop.org/libinput/doc/latest/