Internal touchpads with trackpoints are either BUS_I8042 or BUS_I2C, but not
BUS_USB. Lenovo sells external keyboards with a trackpoint built-in, make sure
we don't pair that trackpoint with the internal touchpad.
And likewise, the internal trackpoint should not be paired with e.g. a wacom
touch device.
Lenovo had one external device that has a trackpoint and a touchpad on an
external keyboard. That device won't be covered with this patch, if we have a
user we can re-consider.
https://bugs.freedesktop.org/show_bug.cgi?id=89935
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Follow-up to e2f61b8fb7.
Scroll events are sent through the pointer interface, so we must set the
capability. Otherwise a caller may not have the required bits set up and is a
bit surprised by events coming out of an interface the device doesn't actually
have (xf86-input-libinput crashes when this happens).
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prints the various pointer accel behaviors into a format understood by
gnuplot, which then provides prettiness.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The main purpose of this patch is to allow the user to actually slow
down pointer movement using libinput_device_config_accel_set_speed, this
is achieved by changing the max-accel setting from "2.0 - speed" to
"2.0 - speed * 1.5", resulting in a max-accel of 0.5 when the user configures
speed at -1.0, the other accel profile parameters are adjusted by the same
factor to keep the curve the same.
This means that the user can get the exact same behavior as before by
multiplying the old setting by 0.6667 (2/3), this also means that this
change not only allows the user to select a slower speed, but to keep
things balanced the same as before, also a higher speed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Less ambiguous since real_touches can be interpreted to "current number of
real touches as opposed to fake touches". Which it isn't, this variable holds
the number of slots.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Up to QUINTTAP, we count fake fingers through the BTN_TOOL_*TAP kernel defines.
Once we exceed QUINTTAP, the nfake_finger count returns to 0 and
tp_unhover_touches terminates all touch sequences. The most visible effect of
this was stopped in 591a41f but the problem remained.
Since we're not using 5 fingers for anything, use that to set the
overflow flag. The kernel gives us either a BTN_TOUCH 0 (all
released) or a lower BTN_TOOL_*TAP to unset the flag when we go below 5
fingers again.
And if we overflow, we can skip the unhovering of touch points since we a)
have a decent touchpad that gives us real touchpoints and b) hovering isn't
supported for 5 touches anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=89800
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is a kernel bug, reject such devices outright. This saves us from a bunch
of extra double checks to make sure that the resolutions are always set up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A switch from BTN_TOOL_FINGER to BTN_TOOL_DOUBLETAP sets the former to 0, then
the latter to 1, within the same frame. In the previous code we'd end the
first touchpoint, then start two new ones immediately after when the DOUBLETAP
comes in. This causes bug notices in the edge scrolling code and finger
miscounts in the tapping code (since neither processes the change, there is no
SYN_REPORT between the two).
Only update the state bits when we get the events, handle the fake touch
sequence start/end on SYN_REPORT instead.
https://bugs.freedesktop.org/show_bug.cgi?id=89949
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regression introduced in 9f8edc5fd8 where it
changed from delta / (dpi/default) to delta * dpi/default, causing the inverse
effect of what the dpi setting is supposed to achieve.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tp->nfingers_down gives us the current state of the touchpad but in the case
of the tapping state we need the touchpoints separately. If all touchpoints
end in the same SYN_REPORT frame, tp->nfingers_down is 0 when we handle the
touch releases. This changes the tap state to IDLE on the first release and
then logs a bug when the remaining touches are released while the touchpad is
in IDLE.
Avoid this by counting the fingers separately for the tap state, this way we
can count up/down with the down/up events as we process them for the tapping
state machine.
This also adds tests for 4 and 5-finger tapping which is how the bug was
discovered in the first place.
https://bugs.freedesktop.org/show_bug.cgi?id=89800
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous code didn't handle fake MT devices without ABS_X/Y axes (like the
Razer BlackWidow keyboard). Those devices usually start at ABS_MISC and go up
to ABS_MAX, thus triggering the Android check.
Split the condition up: if the device is not a fake MT device we check for the
Android missing axes first and add them. Then we proceed, but now we know that
the ABS_X axis must exist on any valid device.
https://bugs.freedesktop.org/show_bug.cgi?id=89783
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libevdev_set_abs_info() is a noop if the event code isn't enabled on the
device. This leaves ABS_X/Y on NULL, causing a crash later when dereferencing
the absinfo.
https://bugs.freedesktop.org/show_bug.cgi?id=89783
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Change vector_get_direction input to a normalized_coords type rather than
passing in a separate x,y pair, and rename it normalized_get_direction to
match. Since it now depends on the normalized_coords type which gets declared
in libinput-private.h also move it to libinput-private.h .
Note this commit also contains a functional change wrt the get_direction
usuage in the palm detection. The palm-detection code was calling get_direction
on non normalized coordinates, this commits changes the code to normalize
the coordinates first. This is the right thing to do as calling get_direction
on non normalized coordinates may result in a wrong direction getting returned
when the x and y resolution of the touchpad are not identical.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
What we really need is not a specific delta type, but a type which can hold
non discrete device coordinates, this is e.g. also needed for the center
coordinates of gestures. So rename delta_coords to device_float_coords to
properly reflect what we really need.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Change tp_filter_motion to use normalized_coords, rather then having it take
separate x and y values.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a normalized_is_zero helper function, and use it where applicable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a normalized_length helper function and use this where applicable,
just a minor cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tp_normalize_coords is one of the last functions taking separate x, y
values rather a coordinate pair, this commit cleans this up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The DEFAULT_SCROLL_THRESHOLD value is a TP_MM_TO_DPI_NORMALIZED value and as
such should be compared to a normalized value. But since commit 8101e43774
("touchpad: switch delta handling to typesafe coordinates"), the
initial_dx / initial_dy values initial_delta points to are no longer in
normalized coordinates, as the result of tp_normalize_delta is now stored
into the normalized value.
This commit changes the check to use the delta pointer which does point to
the normalized x/y values. While at it also use the zero variable to
set normalized to zero rather then manually setting x and y to 0.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Except for a few axes where this may be correct, a min == max axis range
indicates a broken kernel driver. To avoid potential divisions by zero when
scaling this axis later, reject such a device outright.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This reverts commit 0e64837f30.
Rather than a customized touchpad property, let udev handle this and set the
absinfo struct during the normal setup procedures. No need for libinput to
have a custom workaround here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the delta is 0, the distance is the number of units (within this ms). Delta
1 means velocity across 2 ms, etc.
Bonus: this doesn't return infinite speed anymore if we get more than one
event per ms. This can happen on any device approaching 1000Hz poll rate, but
definitely got triggered by the test suite.
Actual effect was limited, since we cap out acceleration at max_accel we just
hit this earlier and it stayed there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Delta movements on most slower movements are less than 1.0 per event, so we'd
end up with an undefined direction for all of them. This led to the velocity
being calculated across opposite movements rather than (as intended) across
movements within a shared octant.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This reverts commit d101d43dd0.
This commit was accidentally merged, it was sitting on top of the wip branch.
With the 0e64837f30 commit this isn't necessary
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A large range of the Apple touchpads seem to have the same dimensions. Use
that fact to force-set a resolution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Not all touchpad kernel drivers supply the x/y resolution. Let the udev hwdb
fix this up where possible and read the value from it.
This is intentionally only used on touchpads, touchscreen devices without
resolution should be considered buggy and fixed in the kernel.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Make the helper function accessible from other places (will be needed in an
upcoming patchset). This also now takes a custom resolution as argument
instead of always setting it to 1, and allows overriding a fake resolution
after the fact.
And instead of a hardcoded 1 everywhere, use a define for the resolution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This way the unaccelerated deltas returned by libinput are correct.
To maintain the current behavior we slow down the input speed by the magic
factor and likewise the accelerated output speed. This produces virtually the
same accelerated deltas as the previous code.
The magic factor is applied to the default denominator for guessing a
resolution based on the touchpad diagonal. We can't really get around this
without having a resolution from the touchpad; meanwhile this produces
virtually the same coordinates before/after.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We really don't need to deal with devices that have x but not y or vice versa.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These devices don't provide ABS_X/Y, but do have proper multitouch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The struct evdev_device's absinfo_x/y point to the right axis
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
