GitLab

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-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/4298Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Christian Hartmann <cornogle@googlemail.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

No functional changes, this affects the declaration only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-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>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Oh gcc warning, where are thou?
Signed-off-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>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Coverity pointed these out, they're false positives but mark them with
comments to make it obvious to the reader.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

When creating uinput devices, we get the devnode from the kernel directly
rather than through udev. When we add this to the path backend too quickly the
udev_device we get may not be fully initialized and properties may be missing.
This causes false test results.

Avoid this by making sure the handle we have is initialized. This should never
trigger on a real device anyway, even creating a device through litest is slow
enough to avoid this issue. Only affected are the tests in misc.c where we
create the uinput device directly.

Nonetheless, handle this for the generic case so we don't run into heisenbugs
later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Makes the code use more commonly used paths, no real functional changes at
this point. This was using hand-crafted devices as it predates the
litest_add_for_device() helper.

For an upcoming patch to use the udev ID_INPUT_. tags the
event_conversion_key test requires this change: without it the device will be
tagged with ID_INPUT_KEY but not ID_INPUT_KEYBOARD. This could be fixed by
adding all normal keyboard keys to the uinput device but it's easier to just
re-use litest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

Note: touchpads have a different backend, we never get here in that case. This
only applies to true absolute pointer devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Don't rely on a magic version tag, instead let a device define a udev rule and
drop that into the udev runtime directory before the device is created.

There are a couple of caveats with this approach: first, since this changes
system-wide state it may cause issues on the device the test suite is run on.
This can be avoided if the udev rules have filter patterns that ensure only
test devices are affected.

Second, the check test suite aborts but it doesn't run the teardown() function
if a test fails. So far this wasn't a problem since uinput devices disappear
whenever we exit. The rules files will hang around though, so an unchecked
fixture was added to delete all litest-foo.rules files before and after a test
case starts. Unchecked fixtures are run regardless of the exit status of the
test but run in the same address space - i.e. no ck_assert() usage.

Also unchecked fixtures are only run once per test-case, not once per test
function. For us, that means they're only run once per device (we use the
devices as test case), i.e. if a test fails and the udev rule isn't tidied up,
the next test may be unpredictable. This shouldn't matter too much though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

The laptops on this series have the physical trackpoint buttons back but
wired them up to the touchpad instead of the trackpoint device and they appear
as BTN_0, BTN_1 and BTN_2 for left, right, middle.

The udev hwdb marks these for us with the TOUCHPAD_HAS_TRACKPOINT_BUTTONS tag
[1]. Use that tag to identify them and re-route the events through the
trackstick device after mangling the event codes to represent the actual
buttons.

[1] http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/70-touchpad.hwdbSigned-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Notable: sends BTN_0/1/2 instead of the trackpoint

This device currently has the INPUT_PROP_TOPBUTTONPAD property set, kernel
patches [1] and [2] are pending to remove this. This test device already lacks
the property.

[1] https://patchwork.kernel.org/patch/5730371/
[2] https://patchwork.kernel.org/patch/5730451/Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>