litest-wacom-touch.c:31:6: warning: no previous prototype for
'litest_wacom_touch_setup' [-Wmissing-prototypes]
and similar
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
litest.c:207:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Intentionally not added to EXTRA_DIST, if you're not running libinput from git
you're not supposed to push documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Button states are applicable to more then just the pointer, so having a
non-generic name name for a generic enumerator value like
libinput_pointer_button_state doesn't make sense. Changing it to something
generic like libinput_button_state allows it to be reused by other devices that
may potentially be added to libinput in the future.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixed point numbers can easily overflow, and double to fixed point
conversion is lossy. Use floating point (double) where fixed point
numbers where previously used and remove the li_fixed_t type.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The direction lock was intended to avoid erroneous horizontal scroll events
when scrolling vertically (and vice versa). Some testing on my touchpad here
shows that it is too easy to accidentally lock the direction when no lock is
intended (e.g. moving around an image). And quite hard to figure out what a
pure vertical gesture is.
I get movements from 90 degrees to 70 degrees for something my brain would
consider vertical scrolling. Depending on the hand position, the fingers
actually perform a slight curve, not a straight line.
Hence - drop the direction lock, but increase the threshold a little. It
doesn't totally avoid horizontal scroll events but keeps them minimal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Avoids having to #define any values we're trying to use.
Header file is from Linux 3.15-rc8.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
struct input_absinfo has the resolution as the 6th field, not as the 4th.
This doesn't have any visible effect because uinput doesn't allow us to set
the resolution yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Resolution for x is 10, 9 for y. And while we're at it set the actual
resolution, not the fuzz.
No actual effect since resolution can't be set through uinput where we use
these devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
event-debug.c: At top level:
event-debug.c:129:1: warning: ‘static’ is not at beginning of declaration
[-Wold-style-declaration]
const static struct libinput_interface interface = {
^
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
misc.c: In function ‘create_simple_test_device’:
misc.c:71:54: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
while ((type = va_arg(args, unsigned int)) != -1 &&
^
misc.c:72:54: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
(code = va_arg(args, unsigned int)) != -1) {
KEY_MICMUTE was added relatively recently (3.1 with 33009557bd: Add
KEY_MICMUTE and enable it on Lenovo X220), so provide a fallback definition
similar to how we do it for KEY_LIGHTS_TOGGLE to fix compilation with older
toolchains.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add support for the top softbutton area found on some laptops.
For details of how this works, see the updated
doc/touchpad-softbutton-state-machine.svg diagram.
Basically this mirrors the state-machine for the bottom softbutton area, with
one exception, if a finger stays at least inner timeout milliseconds in the
top button area and then moves out of it, it will be ignored rather then
become the pointer. This is done so that people using the top buttons together
with a trackstick and accidentally move their finger out of the upper area
don't get spurious pointer movements from the finger on the trackpad.
This behavior is indentical to xf86-input-synaptics, which also ignores
movements from touches which start in the top button area.
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>
Rename some clickpad softbutton area variables to have bottom in their
name, this is a preperation patch for adding top softbutton area support.
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>
When we knowingly hit a bug, we should know what the bug is caused by. Log
that in a standardized fashion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
I'm not sure what exactly is happening here, but while valgrind seems to run
fine in normal mode, the build from make distcheck fails with rather random
errors. Disabling CK_FORK seems to help, but more investigation is needed.
Meanwhile, this makes distcheck succeed again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
With the addition of software buttons for clickpads, the new touchpad code has
overtaken this driver in terms of features. The older driver was disabled in
6a61032625.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Devices that are direct input devices are marked by the kernel with the
INPUT_PROP_DIRECT property. Touchpads are always indirect input devices, so
let's do the easiest check first before we try device-specific capabilities.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
calculate_velocity() didn't skip pointer trackers far away in time when
calculating the initial velocity. This check was done later when
iterating the rest, so while at it, simplify the function by doing both
iterations in one single loop.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Short vectors alongside the x axis produced inverted directions.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The x and y absolute axis may have different resolutions, meaning 1 unit
long motion delta on one axis is not physically as long as 1 unit motion
delta on the other axis.
In order to make these anisotropic input motion deltas output as isotropic
motion deltas, apply scaling to one of the axis making it have the same
dimension as the other, before passing it through the motion filter
which assumes all deltas are isotropic.
https://bugs.freedesktop.org/show_bug.cgi?id=79056
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This patch reimplements the simple smooth pointer acceleration profile
from X.org xserver. The algorithm is identical to the classic profile
with a non-zero pointer acceleration threshold.
When support for changable parameters is in place, to get a pointer
acceleration the same as the default classic profile of X.org a
polynomial acceleration profile should be used for when the threshold
parameter is zero.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Pointer acceleration filters may absorb the first event, so queue two,
just in case.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A test cannot exactly predict the resulting motion event from a given
evdev event series without having to reimplement the acceleration
algorithm. To still be able to test that sane relative motion events are
produced, check that the length and direction of the resulting motion
event vectors are close to the same as the expected vectors.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On a button click / tap the scrolling event handler no longer gets called,
ensure that any in progress scrolling is stopped.
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>
Put the actual scroll event posting in the straight path.
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>
Setting tp->scroll.direction = 0 before checking tp->scroll.direction
to see if we need to send stop scroll events for vert / horz scrolling does
not really work well.
Also we need to check direction with an axis mask, not the axis number.
While at it also add a tp_stop_scroll_events() helper function for this.
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>
When doing 2 finger scrolling we don't want any spurious movement events after
scrolling. touchpad_2fg_no_motion tests for this, but it lifts touch 0
(which is the pointer as it came down first) first, so it only catches the
case where touch 1 suddenly gets promoted to being the pointer.
However if touch 1 is lifted first, then touch 0 is still the pointer and
will cause spurious movement events. Swap the 2 litest_touch_up calls to
catch this (and make the test fail), and add code to clear the is_pointer
flag on all touched when doing 2 finger scrolling to fix it again.
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>
Alter the so far hard coded parameters a bit to make the pointer
acceleration profile accelerate the pointer movement a bit more than
before.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We store timestamps in ms since system boot (CLOCK_MONOTONIC). This will wrap
after circa 50 days.
I've considered making our code wrapping safe, but that won't work. We also
use our internal timestamps to program timer-fds for timeouts. And we store
ms in a single integer but the kernel uses 2 integers, one for seconds and
one for usec/nanosec. So at 32 bits our ms containing integer will wrap
in 50 days, while the kernels seconds storing integer lasts a lot longer.
So when we wrap our ms timestamps, we will be programming the timer-fds
with a seconds value in the past.
So change all our internal timestamps to uint64_t to avoid the wrapping
when programming the timer-fds. Note that we move from 64-bit timestamps to
32-bit timestamps when calling the foo_notify_bar functions from
libinput-private.h. Having 64 bit timestamps has no use past this point,
since the wayland input protocol uses 32 bit timestamps (and clients will
have to deal with wrapping).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is no longer needed now that we take the button area and pinned fingers
into account.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
