GitLab

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

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

Signed-off-by: Mihail Konev <k.mvc@ya.ru>

Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent
fall-outs, when they contain space.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

By default, the X server maps the tablet axes to the available screen area.
When a tablet is mapped to the screen but has a different aspect ratio than
the screen, input data is skewed. Expose an area ratio property to map the
a subsection of the available tablet area into the desired ratio.

Differences to the wacom driver: there the x/y min/max values must be
specified manually and in device coordinates. For this driver we merely
provide the area ratio (e.g. 4:3) and let the driver work out the rest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>

Takes a 4-point cubic bezier curve as input and maps the pressure coordinates
to the values outlined by this curve. This is an extension of the current
implementation in the xf86-input-wacom driver which only allows the two center
control points to be modified.

Over the years a few users have noted that the wacom driver's pressure curve
makes it impossible to cap the pressure at a given value. Given our bezier
implementation here, it's effectively a freebie to add configurability of the
first and last control points. We do require all control points' x coordinates
to be in ascending order.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Needed for the wacom stylus pressure curve
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

For a mouse with a click angle of 15 degrees things are unchanged. For devices
with angles less than 10, the current code scrolled way too fast. Because the
angle wasn't used anywhere, each tick would count as full scroll wheel event,
a slight movement of the wheel would thus scroll as much as a large movement
on a normal mouse.

Fix this by taking the actual click angle of the device into account. We
calculate some multiple of the angle that's close enough to the default 15
degrees of the wheel and then require that many click events to hit the full
scroll distance. For example, a mouse with a click angle of 3 degrees now
requires 5 clicks to trigger a full legacy scroll button event.

XI2.1 clients get the intermediate events (i.e. in this case five times
one-fifth of the scroll distance) and can thus scroll smoothly, or more
specifically in smaller events than usual.

https://bugs.freedesktop.org/show_bug.cgi?id=92772Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

The only difference here is the axis number.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Changed this during development because I forgot that the value actually
matters (for touchpads anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

If an XKB AccessX timeout is set and a VT switch is triggered, the
AccessXTimeoutExpire function may be called after the device has already been
disabled. This can cause a null-pointer dereference as our shared libinput
device may have been released by then.

In the legacy drivers this would've simply caused a write to an invalid fd
(-1), not a crash. Here we need to be more careful.

https://bugs.freedesktop.org/show_bug.cgi?id=98464Signed-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>

Was exposing the evdev code rather than the xorg code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

The parent device ref's the libinput device during pre_init and unref's it
during DEVICE_INIT, so the copy is lost. During DEVICE_ON, the libinput device
is re-added and ref'd, this one stays around now. But the takeaway is: unless
the device is enabled, no libinput device reference is available.

If a device is a mixed pointer + keyboard device, a subdevice is created
during a WorkProc. The subdevice relied on the parent's libinput_device being
available and didn't even check for it. This WorkProc usually runs after
the parent's DEVICE_ON, so in most cases all is well.

But when running without logind and the server is vt-switched away, the parent
device only runs PreInit and DEVICE_INIT but never DEVICE_ON, causing the
subdevice to burn, crash, and generally fail horribly when it dereferences the
parent's libinput device.

Fix this because we have global warming already and don't need to burn more
things and also because it's considered bad user experience to have the
server crash. The simple fix is to check the parent device first and if it is
unavailable, create a new one because it will end up disabled as well anyway,
so the ref goes away as well. The use-case where the parent somehow gets
disabled but the subdevice doesn't is a bit too niche to worry about.

This doesn't happen with logind because in that case we don't get a usable fd
while VT-switched away, so we can't even run PreInit and never get this far
(see the paused fd handling in the xfree86 code for that). It can be
reproduced by setting AutoEnableDevices off, but why would you do that,
seriously.

https://bugs.freedesktop.org/show_bug.cgi?id=97117Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

The property is tablet-wide, not just per tool. So when one tool is updated,
run through all other devices that share the same underlying device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Exit early if the string is NULL to reduce indentation. No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Now that we sort below the xf86-input-wacom driver anyway, there's no good
reason to ignore tablets anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

This device never sends events, no point in exposing these options
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>

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

is_libinput_device(next) causes a dereference of next anyway, so this cannot
ever be NULL.

Besides, if next ends up as NULL that means we have lost count of how many
remaining devices use libinput, so we have other issues.

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

They were never used anyway
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>

Missing from a790ff35Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

If we don't swap out the pInfo previously passed to xf86AddEnabledDevice(),
the thread eventually calls read_input on a struct that has been deleted.
Avoid this by swapping out the to-be-destroyed pInfo with the first one we
find.

Reproducer: sudo udevadm trigger --type=devices --action=add
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Copy/paste error

https://bugs.freedesktop.org/show_bug.cgi?id=97989Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

If --prefix isn't specified on the command line, $prefix contains "NONE"
at this point, not the default prefix value. So make install would
attempt to install the xorg.conf.d snippet to
${DESTDIR}NONE/share/X11/xorg.conf.d/.

Avoid this by leaving ${prefix} verbatim in the default value, to be
resolved by make.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This looks like a cut&paste coding error to me, and it generated a
compiler warning about possibly uninitialized value.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Clear typo. Not bothering to be backwards compatible here, anything that uses
the #define will update on rebuild, anyone using the string directly should've
told me about the typo...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Avoid creating new devices from within the input thread which was the case for
tablet tools. It requires a lot more care about locking and has a potential to
mess up things.

Instead, schedule a WorkProc and buffer all events until we have the device
created. Once that's done, replay the event sequence so far. If the device
comes into proximity and out again before we manage to create the new device
we just ditch the whole sequence and wait for the next proximity in.
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>

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

This is the continuation of 3f569ec4, dropping libinput below the remaining
drivers. Wacom and synaptics already sort higher anyway (see wacom commit
0da5cd54 and synaptics commit 59e5db025). evdev remains the catchall
basic fallback driver and is overwritten by libinput. The two drivers affected
by this patch are joystick and vmmouse.

joystick is a niche driver and drives devices libinput doesn't handle anyway
so there is no need to override. If a user installs it, presumably it is to
use it.

vmmouse is a niche driver and does not assign itself anymore for newer kernel
drivers (see vmmouse commit 576e8123 from Oct 2014). So if vmmouse is
installed it can safely sort higher than libinput.

Note: this is upstream behavior, distributions have to work out the wanted
behavior themselves by renaming the config snippets accordingly.
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>

There is not good wire protocol for pad modes so instead we just export the
information via properties. One property to tell us how many groups and how
many modes each group has. One property for the current mode of each group.
And three properties to tell us which group each button, ring and strip is in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The list returned by xf86FirstLocalDevice() includes our own device. If the
parent device is removed before the hotplug callback is invoked, the first
match with the same shared-device ID is our own device (or potentially another
subdevice on the same already-removed parent). Avoid this by making sure the
matched device is actually a parent device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Keith Packard <keithp@keithp.com>