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>
The current code tried to emulate the relative motion to be equivalent to the
absolute motion, except in screen coordinates. This is way too slow for the
cursor tool that we want to behave like a mouse.
Tablets have high resolution (e.g. an Intuos 4 is a 5080dpi mouse) and that
motion is way too fast to be usable. Scale it down to match a 1000dpi device
instead. Since the cursor and lens tool are still high precision devices leave
them in a flat acceleration profile without actual acceleration.
For the stylus-like devices leave the current accel, pointer acceleration on a
stylus is hard to handle.
This also adds the missing bits for actually using the speed factor set
through the config interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
The x/y tilt angle comes in as degrees, so our scale could be as large as 90x
the original size. Scale to something more sensible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move mode control to libinput. This reduces some flexibility on what we can do
with modes but makes it a lot easier for anyone to implement modes correctly
and have the LEDs apply appropriately, etc. Let's go with the option to make
the 95% use-case easy. Note: whether the mode is actually used is up to the
caller, e.g. under Windows and OS X the mode only applies to the
rings/strips, not the buttons.
A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned
to a mode group. That group has a numeric mode index and is hooked to the
LEDs. libinput will switch the LEDs accordingly.
The mode group is a separate object. This allows for better APIs when it comes
to:
* checking whether a button/ring/strip is part of a mode group
* checking whether a button will trigger a mode transition
and in the future potentially:
* checking which mode transition will happen
* setting which button should change the mode transition
* changing what type of mode transition should happen.
* moving a button from one mode group to the other
This patch adds the basic scaffolding, without any real implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Proofread-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
