If a device is split into multiple subdevices, usually pointer+keyboard, we
initialized properties matching the libinput device on both devices. This
results in the keyboard having e.g. a Accel Speed or Left Handed settings even
though it cannot send any events of that type.
Filter by capabilities on the subdevice so we only get those properties that
match the subdevice's capabilities.
https://bugs.freedesktop.org/show_bug.cgi?id=100900
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch splits the meat of xf86libinput_handle_tablet_axis into a helper
function xf86libinput_post_tablet_motion(), to be called right after we send
the proximity in event.
Clients that don't handle proximity (e.g. all XI2 clients) don't see the
coordinates we send along with the proximity events. And, for historical
reasons, they may not look at the coordinates in button events. So a device
that comes into proximity and immediately sends a tip down button event
doesn't send a motion event, causing the client to think the tip down was at
whatever the last known position was (before previous prox-out).
The practical effect is that when a user tries to draw a few dots, they end up
being connected to each other.
https://bugzilla.redhat.com/show_bug.cgi?id=1433755
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Caused by different results in -O0 vs -O2. The resulting array differs only
slightly but the initial sequence has one extra zero. That triggers our
assert, no other compiler flag seem to be affecting this.
Compiled with -O0:
Breakpoint 1, test_nonzero_x_linear () at test-bezier.c:157
157 assert(bezier[x] > bezier[x-1]);
(gdb) p bezier
$6 = {0 <repeats 409 times>, 1, 2, 4, 5, 7, 9, 10, 12, 14, 15, 17, 19, 21, 22,
Compiled with -O2:
(gdb) p bezier
$1 = {0 <repeats 410 times>, 1, 3, 5, 7, 9, 10, 12, 14, 15, 17, 19, 20, 22,
Printing of the temporary numbers in the decasteljau function shows that a few
of them are off by one, e.g.
408.530612/0.836735 with O0, but
409.510204/0.836735 with O2
Note: these are not rounding errors caused by the code, the cast to int
happens afterwards.
Hack around this by allowing for one extra zero before we check that the rest
of the curve is ascending again.
https://bugs.freedesktop.org/show_bug.cgi?id=99992
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only use-case here are pad mode LEDs that now live in /sys/class/leds. Asking
the server to open them is pointless, the server only knows how to open Option
"Device". And since the LEDs are in sysfs we should have access to them
anyway, so no need for jumping through or hula-ing hoops.
xf86CloseSerial() works as intended as it's a slim wrapper around close(), so
we only have to worry about the open() path here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Updating the property directly causes us to send events from the input thread
which has some "interesting" side effects like messing up the reply order or
just crashing the server.
Schedule a work proc instead and update it whenever the server is back in the
main thread.
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>
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=92772
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=98464
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=97117
Signed-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>
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>
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>
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>
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>
This is the continuation of 3f569ec493, 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>
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>
