libinput applies averaging to the velocity of most pointer devices. Averaging
the velocity makes the motion look smooth and may be of benefit to bad input
devices. For good devices, however, it comes at the unfortunate price of
decreased accuaracy.
This change turns velocity averaging off by default (sets ntrackers to 2 instead
of 16) and allows for it to be turned back on via a quirk, for bad devices which
require it.
Only one place really needs the return argument, so we might as well just pass
the memory to be returned in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Measuring the trackpoint range has not shown to be sufficient or precise
enough to be used as an ingredient for trackpoint acceleration. So let's just
switch back to a generic multiplier that we can apply to the input deltas do
undo any device-specific lack of scaling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the meson build type is something other than the debug types, we don't
need the special behavior where we adjust executable paths and data dir
lookup for tools run directly from the builddir.
This avoids leaking the build dir into the final executables.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running libinput tools from the builddir, look up the subtools in the
builddir as well. Otherwise, add the install prefix to the list of lookup
locations.
This ensures that a) we're running builddir stuff against builddir stuff, but
also b) that we're not running builddir stuff against installed stuff because
that may give us false positives.
The test was squashed in from a separate patch and was
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This way we can re-use this from libinput-record instead of having to
duplicate all this. Since the two tools use different printfs, just make the
actual printing a simple callback.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
My kingdome for a compiler warning. Or a scan-build warning. Or a coverity
warning. Or anything... But no, nothing.
Also make the open_restricted() more robust to a NULL userdata, because
effectively that's what we were passing here.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/50
Introduced in 0a13223c39
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The &grab pointer we used to pass as userdata was the address of the function
argument which goes out of scope at the end of the function. This works fine
for devices immediately opened but when a device connects later, the address
may have been re-used since and it's content is undefined. If not NULL, we
end up grabbing the device.
Instead pass the grab option in which is guaranteed to live until the end of
main.
https://gitlab.freedesktop.org/libinput/libinput/issues/26
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses" and whatnot (some notable exceptions in e.g. bug 101139).
Attempts to change the actual acceleration function will likely break things
for others.
This approach opens up the profile itself to a user-specific acceleration
curve. A caller can set an acceleration curve by defining a number of points
on that curve to map input speed to an output factor. That factor is applied
to the input delta.
libinput does relatively little besides mapping the deltas to the
device-specific speed, querying the curve for that speed and applying that
factor. The curve is device-specific, the input speed is in device units/ms.
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>
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>
This is the first tool of many more to come to enable users to gather
information aobut their devices and/or usage of these devices. Previously,
these required the users to record events, submit them to a bugzilla, have me
run various scripts over it and then decree that the scripts have spoken.
Push some of this into the hands of the users so they can query the numbers
locally and start investigating (or at least get an idea of what's happening).
This tool measures the time deltas between touch up and touch down and prints
a basic summary, together with the ability to print a dat file with the data
for visualization by e.g. gnuplot. Eventually, more of the current analysis
scripts will be moved into this or other helpers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the debug-gui is a user-visible tool, make sure the usage reflects
the right command name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Chaining args together inside a single binary would be nice, but it gets nasty
quickly (as I found out adding 3, 4 extra commands). Switch over to using a
git-style exec-ing command where libinput merely changes argv[0] and then
executes whatever it assembled. And those binaries can hide in libexec so they
don't clutter up the global namespace.
This also makes it a lot easier to write man pages, adopt the same style as
git uses.
Compatibilty wrapper scripts are provided for libinput-list-devices and
libinput-debug events. These warn the user about the changed command, then
exec the new one. Expect these wrappers to be removed at some point in the
future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
../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>
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>
There are a number of use-cases where tapping may be desirable, but
tap-and-drag is not, e.g. where tapping is used to select multiple items in a
list. Having tap-and-drag on hinders this, and the nature of the interaction
means it cannot be detected based on timeouts, movement thresholds, etc.
Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
enabled by default (though tapping is disabled by default).
For the touchpad tap state diagram, the new option disables the transition
from state TOUCH to state TAPPED and releases the button immediately instead.
This means that multitap-and-drag is disabled too since we now just loop
around in the single-tap state for multitap.
It also makes tapping more responsive - we don't have to wait for the timeout
before we know whether it's a tap event. The first touch time is noted, we now
send the button press with the time of the first touch and the release with
the time of the release. This ensures a realistic time diff between the two
events.
https://bugs.freedesktop.org/show_bug.cgi?id=93502
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.netto>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The quartett of new config functions is:
libinput_device_config_accel_get_profiles
libinput_device_config_accel_get_profile
libinput_device_config_accel_set_profile
libinput_device_config_accel_get_default_profile
The profile defines how the pointer acceleration works, from a very high-level
perspective. Two profiles are on offer, "adaptive", the standard one we have
used so far and "flat" which is a simple multiplier of input deltas and
provides 1:1 mapping of device movement vs pointer movement.
The speed setting is on top of the profile, a speed of 0 (default) is the
equivalent to "no pointer acceleration". This is popular among gamers and
users of switchable-dpi mice.
The flat profile unnormalizes the deltas, i.e. you get what the device does
and any device below 800dpi will feel excruciatingly slow. The speed range
[-1, 1] maps into 0-200% of the speed. At 200%, a delta of 1 is translated
into a 2 pixel movement, anything higher makes it rather pointless.
The flat profile is currently available for all pointer devices but touchpads.
https://bugs.freedesktop.org/show_bug.cgi?id=89485
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
