Behavior for axis events in the same event frame as the BTN_TOUCH is to
always send axis events before any tip state.
Behavior for button events in the same event frame as the BTN_TOUCH is to
order button events to happen when the tip is in proximity, i.e. after the tip
event on tip down and before the tip event on tip up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The tablet tip works like a button in the kernel but is otherwise not really
a button. Split it into an explicit tip up/down event instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tap-tap-down-move should emit 1 click + press, not 2 clicks + press
https://bugs.freedesktop.org/show_bug.cgi?id=92016
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
If a caller has a reference to a device group when the context is destroyed,
the memory for the group is never released. Calling
libinput_device_group_unref() will release it and there are no side-effects
since the group has no back-references. It's inconsistent with the rest of
libinput though - all other resources get released on libinput_unref().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The following sequence currently generates a right-button event:
finger 1 down
finger 2 down
finger 1 up
finger 2 held down
This is easily triggered with short scroll events. There are two issues here:
first is that the tapping code elsewhere treats any tap with a second finger
down as a left-button tap, not a right button one. So if anything, we should
generate a left button click here, not a right button click.
Arguably, generating a button click here is wrong though, it's not a very well
defined sequence and relatively difficult to trigger intentionally. So the
best solution here is to simply ignore the release event and move straight
back to state HOLD - unless the second finger is released within the timeout.
If the finger is set down again during the timeout, we move straight to
TOUCH_2_HOLD - this could eventually be interpreted as a tap, but not for now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
With this change auto assign events will be skipped if no replacement value
is provided. This behavior is practical when emitting mt events, as those
only contain the axis values that changed.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test is supposed to test for the timeout kicking in on edge scrolling -
if the finger is in the edge for longer than the timeout, we switch to
scrolling without requiring the motion threshold to be met first.
To emulate this, move the finger ever so slightly first to load up the motion
history, then timeout, then move. We expect a bunch of motion events with a
small delta.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes the code more straightforward, and we now require the devices to
have a height/width anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A device with REL_X/Y and keys gets marked only as ID_INPUT_KEY, initializes
as keyboard and then segfaults when we send x/y coordinates - pointer
acceleration never initializes.
Ignore the events and log a bug instead. This intentionally only papers over
the underlying issue, let's wait for a real device to trigger this and then
look at the correct solution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Instead of going straight to pointer_notify_axis, go through
evdev_notify_axis() which flips the scroll direction around for us.
https://bugs.freedesktop.org/show_bug.cgi?id=91597
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The first finger is accurate, it's just the second finger that is imprecise,
so we can't handle it as a true touch. Instead, revert the device back to
being a single-touch touchpad and use the fake touch bits for second finger
handling.
Two-finger scrolling thus becomes usable though we will lose out on
other features like thumb detection. Useful scrolling trumps that though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Follow-up to eb146677e, if we disable 2fg scrolling on those touchpads we
should also disable gestures. The data doesn't magically become more useful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Only abort on client or libinput bugs, skip over kernel bugs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
98346f6a1a added a warning about timeouts expiring before now. Those warnings
are triggered by a bunch of tests where we have events, then a timeout, then a
libinput_dispatch().
All these are bugs in the test, since we can't guarantee the order of fds (and
thus which fd the events are pulled off first) it's just lucky that they worked.
Insert the required libinput_dispatch() calls.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Add a LIBINPUT_TEST_DEVICE udev parameter to test devices created by
the test suite. When an application tries to add such a device to the
path backend or when the udev backend discovers such a device, it will
be ignored. Only the context when run via the test suite will actually
handle these devices.
Doing this will enable a user to run the libinput test suite on a system
running libinput without having the test suite devices interfering with
the actual system.
Note that X.org users running an input device driver that is not the
libinput X input driver will still need to manually configure the X
server to ignore such devices (see test/50-litest.conf).
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is to make room for more types of rules files.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In order to provide higher precision event time stamps, change the
internal time measuring from milliseconds to microseconds.
Microseconds are chosen because it is the most fine grained time stamp
we can get from evdev.
The API is extended with high precision getters whenever the given
information is available.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We currently rely on an extra millisecond being added by the filter
code to get a velocity that are small enough to not hit the max
acceleration limit. If this arbitrary millisecond is changed (for
example by changing the internal time measurment to microseconds and
adding just a microsecond instead), the velocity may change so that the
maximum or minimum acceleration is always hit.
Adding a delay to the test won't work either since it would not only rely
on ending up within the acceleration limits but there would also be an
non-deterministic actual delay causing the velocity of the movement
after the direction change to be potentially larger than the movement
in the original direction due to the actual time delta in libinput will
not always be 1ms.
To fix the test to not rely on any artificial delays in the filter code
nor any non-deterministic delays in the test, lets just test that the
direction change of the hardware events resulted in a direction change
of the libinput motion events.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
These touchpads have a terrible resolution when two fingers are down, causing
scrolling to jump around a lot. That then turns into bug reports that we can't
do much about, the data is simply garbage.
https://bugs.freedesktop.org/show_bug.cgi?id=91135
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
It's reasonable to expect a thumb (or the other hand's index finger) to click
a button while a finger is down for movement. It's less reasonable to expect
this when two fingers are interacting with the touchpad, or when two fingers
click the touchpad (even on a large touchpad that's an awkward position).
Simplify the clickfinger detection mechanism - if we have three touches down,
it's always a three-finger click. Two fingers may be a right click or a index
+ thumb click.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
