And merge all current API versions into the same block. This isn't technically
necessary since removing libinput_has_button from the code will remove it from
the exported list. That trips up test/symbols-leak-test though.
Since we break the API and bump the soname in this release anyway, move
to a single block so the initial stable API is all nicely grouped together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This affects the touch device on graphics tablets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Clickpads have BTN_LEFT but no BTN_RIGHT, non-clickpads must have both.
Tablet touch devices don't have any buttons, so skip the warning for those.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Works as a touchpad but has no buttons.
Minor change to one of the touchpad tests: because the touch area is so big
the slow-scrolling trigger needs to be adjusted.
And because the device is an external device, the "disable on external mouse"
test needs to be adjusted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These tests make sure we don't get tapping events in certain situations
(finger movement, timeouts, ...). Tapping must be enabled for that to be a
valid test.
The tests can't work on semi-mt devices because we can't end slots
independently. Disable the tests there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If we send BTN_LEFT or similar, we need the LITEST_BUTTON capability on the
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Split out into a btntool test and a true three-finger test. For consistency,
check the number of slots on all those tests rather than having
litest-device-specific exclusions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No effect, all devices currently have tapping disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The event sequences we use for plam detection trigger tap events if enabled by
default. Always disable tapping, a set of tests for tapping in the palm
exclusion zones. Arguably, tapping in the zones should be handled in a
separate set of tests though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have real support for them yet but they have the ID_INPUT_TABLET tag
set. Ignore them explicitly before someone thinks they're already working.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-and-tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the device doesn't have any slots, mtdev->caps.slot.maximum is 0. Since we
only use mtdev if we don't have slots, this caused protocol A devices to
always fail.
https://bugs.freedesktop.org/show_bug.cgi?id=89211
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The two tp_get_*_touches_delta functions are almost identical, refactor
them into one function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Only look at real touches when getting the average touches delta, otherwise
the touch used to populate the fake touches gets an unfair weighing factor.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Just moving some code around, no functional changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Handle everything which is not handled by the tap, (soft)button or edge-scroll
code/statemachines in a unified way. Everything is treated as a X-finger
gesture now, and the action to take on finger movement is decided by
the gesture.finger_count setting. Pointer control now simply is seen as a
1 finger gesture, and 2fg scrolling as a 2fg gesture.
This removed the need for special-casing things like switching back to
pointer mode when lifting a finger in 2fg scrolling mode, and also lays the
groundwork for adding 3+ fg gesture support.
Note that 1 test-case needs to be updated to wait for the finger mode
switching when switching mode while a gesture has already been started.
This is actually an improvement as this stops sending spurious pointer
motion events at the end of 2fg scrolling when not lifting both fingers at
exactly the same time.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a tp_get_average_touches_delta helper function, and rename
tp_get_active_touches_delta to tp_get_combined_touches_delta to better
differentiate the two.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Not only stop 2fg scrolling, but also edge scrolling when the trackpoint
becomes active.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
With the upcoming gesture support 2fg scrolling will be handled as part of
the main gesture state machine, whereas edge scrolling has its own state
machine, our current way of dispatching scroll "actions" does not play well
with this.
Change the scroll method handling to treat edge and 2fg scrolling as 2
separate state machines. The double scroll calls this introduces will mostly
be removed when the gesture handling code lands.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
seat_button_count
seat_key_count ... uninitialized variable
t = zalloc
s = zalloc ... dereferencing potential NULL-pointer
d->ntouches_down... side-effect in assertion
Coverity run against the 0.10.0 tag, see
https://scan.coverity.com/projects/4298
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Christian Hartmann <cornogle@googlemail.com>
If the device disappears too quickly, the device is NULL, the sysname is NULL
and that causes a segfault in strcmp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Bluetooth tablet devices' rules can't tag the event node directly, they can
only tag the first parent (the /sys/class/input/input1234 node). Check that
parent for tags too, lest we miss something important.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Store it as identifier in the device group, any two devices that have a
the same non-NULL identifier share the group.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The easiest way to get a device group is by looking at the phys path of the
input device (which looks like usb-0000:00:14.0-1/input1) and dropping the
/inputX bit. The rest is the same for devices that belong together (except on
the Cintiq 22HD Touch).
Ideally we could just take ATTRS{phys} but we can't select substrings to drop
into ENV so we need to do it ourselves. This patch adds a callout that takes a
syspath and prints the mangled path, to be used in LIBINPUT_DEVICE_GROUP.
The rule triggers on any device that has a non-zero phys attribute, this
groups devices like tablets together but also devices like mice with multiple
interfaces.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If a device has multiple capabilities, has_button is imprecise. A device with
tablet and pointer capability for example may have BTN_LEFT on the pointer
interface but not on the tablet interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch adds simple script that compares libinput.sym file to the
functions that are marked by LIBINPUT_EXPORT. This script is added
to make check target.
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use ID_INPUT_FOO to assume a device is a FOO, don't decide ourselves based on
whatever bits are available. This moves the categorization out to udev's
input_id builtin by default and other bits that tag the device. libwacom tags
all known devices as ID_INPUT_TABLET and (for touch-enabled ones)
ID_INPUT_TOUCH - we can re-use that knowledge then.
Ignore anything that doesn't have ID_INPUT set, this provides for an easy way
of making devices "invisible" to libinput.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
udev already tags the devices by opening each of them and analyzing their
features. We are basically re-doing this in libinput.
The advantage of udev tags over the plain heuristic from libinput is that
users (or driver writers) can force some tags that are not detected by
common rules. For instance, the pad part of the Wacom tablets is difficult
to discriminate from a joystick or a pointer.
For now we tread INPUT_ID_KEY and INPUT_ID_KEYBOARD as equivalent. It may
become necessary to separate them later.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This can happen a lot easier on the new Lenovo series, so document that this
is intentional behavior.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Devices like Wacom tablets have multiple event nodes (touch, pad and stylus).
This requires some logical grouping, e.g. setting an Intuos 5 tablet
left-handed effectively turns it upside down. That then applies to both the
stylus and the touch device.
Merging the devices into one struct libinput_device is not feasable, it
complicates the API for little benefit. A caller would still need access to
all subdevices to get udev handles, etc. Some configuration options apply to
the whole device (left-handed) but some (may) only apply to a single subdevice
(calibration, natural scrolling).
Addressing this would make the libinput API unwieldly and hard to use.
Instead, add a device group concept. Each device is a member of a device
group - a singleton for most devices. Wacom tablets will have a single group
across multiple devices, allowing the caller to associate the devices together
if needed.
The API is intentionally very simple and requires the caller to keep track of
groups and which/how many devices are in it. The caller has more powerful
libraries available to do that than we have.
This patch does not address the actual merging of devices into the same
device group, it simply creates a new group for each new device.
[rebased on top of 0.10]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
When using libinput with xf86-input-libinput, the device speed is
represented as a float passed via X properties.
If a buggy client gives a broken value, the conversions that occur
can cause the value of speed to be NaN (not a number), aka infinity.
In C, any comparison with NaN always gives false, whatever the value.
So that test in libinput_device_config_accel_set_speed():
(speed < 1.0 || speed > 1.0)
will necessarily return FALSE, defeating the test of range.
However, since since any comparison with NaN is false, the
opposite assert() in accelerator_set_speed():
(speed >= 1.0 && speed <= 1.0)
will be false as well, thus triggering the abort() and the crash of
the entire X server along with it.
The solution is to use the same construct in both routines, so that
it fails gracefully in libinput_device_config_accel_set_speed().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
