This tool will eventually replace the different libinput tools we ship atm
with the various functionalities being commands to the single tool, rather
than multiple tools.
Right now, we still build both tools separately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Include the source files directly, we'll need per-target compiler flags that
affect different tools differently in the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Print the axis values on proximity out because it a) ensures we have the right
values and b) makes the output better aligned with the proximity in, so it's
easier to spot in a log file. But don't print the tool capabilities because
they're unrelated to the prox out anyway and again it makes the output easier
to spot.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't cater for the special case of groups having a different number of
modes, there is no hardware right now that does that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Supresses any printf statements from the tool itself, i.e. it skips printing
any of the events.
Makes it easier to debug the internal state since it's not intermixed with a
whole lot of messages about the events that are generated. Best combined with
--verbose (yes, hilarious, isn't it...)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
The range that matters is 0-200, maybe up to 400 if you account for really
fast movements. But to match other, published, accel curves default to up to
1000 mm/s. It's easy enough in gnuplot to reduce the range.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Missing from 8c1aa1de where we hid the human-readable parts but the keycode
itself is still enough information to recover the typed bits.
Print it as -1 as that keycode doesn't exist for real keys so it stands out
nicely.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
makes it easier to filter out debugging messages
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libinput-debug-events prints keycodes as they come in. This makes it dangerous
to be run by users (especially in the background) because it will leak
sensitive information as it is typed. Obfuscate the base set of keycodes
by default, require a --show-keycodes switch to show it.
The few times we actually need the keycodes, we can run the switch in the
debugging tool.
This does not affect keys outside of the main block on the keyboard (F-keys,
multimedia keys).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This will allow switch devices known to libinput to be exposed. Currently,
this is SW_LID.
libinput also handles switch events internally, e.g. a laptop touchpad will
be disabled autmoatically when the lid is closed. This is transparent to
the caller, although the caller will also receive the event. See
https://bugs.freedesktop.org/show_bug.cgi?id=86223
This features is intended to be the main driver for the interface.
Co-Authored-By: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: James Ye <jye836@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
../tools/shared.h:66:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
void tools_usage();
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Fixes the respective clang warnings
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
This makes it clear that it's not meant to be dereferenced.
CC: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We print the sysname, but it's not always obvious when there's an event from
another device within the stream from another device. Prefix it so it's easier
to spot and search for.
See https://bugzilla.redhat.com/show_bug.cgi?id=1364850#c3 for an example of
how such an event can hide.
We only use last_device for comparing pointer values so we don't need a
reference to the device, it doesn't matter if the device itself goes out of
scope.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previously hardcoded button map for tapping is 1/2/3 to LRM. But the
middle button is a common feature on the desktop (used for paste, most
prominently) and three-finger tapping is almost impossible to do reliably on
some touchpads (e.g. the T440 has a recognition rate of ~1 in 5).
Left and right buttons have a prominent physical position (either softbuttons
or physical buttons) so make the tap order configurable. Those that require
middle buttons reliably can use the [software] buttons for left/right and
2-finger tap for a middle button.
https://bugs.freedesktop.org/show_bug.cgi?id=96962
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
