For logind-setups we need to match the path libinput wants to open with the
Option Device path that the device has so we know when to return the
server-fd. This doesn't work for by-id or by-path because libinput resolves
those (through udev) to the actual eventX node so our paths look different
when they are the same device.
This could be fixed but since this is easy enough to work around with a
InputClass section and rather a niche case, it's not really worth the effort.
https://bugs.freedesktop.org/show_bug.cgi?id=105562
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Properties are initialized on the correct devices only but on resume we'd just
blindly apply the config from our device. Depending on the resume order, this
would mean we'd apply a previously set config with a default config.
Example:
* pointer device with keyboard subdevice
* pointer device exports natural scrolling, keyboard device does not and
remains at default (off)
* client enables natural scrolling on the pointer device
* VT switch away, VT switch back
* pointer device gets enabled first, enables natural scrolling on the
libinput device
* keyboard device gets enabled second, resets to the default value
Reported-by: Yuxuan Shui <yshuiv7@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Yuxuan Shui <yshuiv7@gmail.com>
87f9fe3a6fafe60134c6's intention was to not create properties that a subdevice
doesn't have configuration options for (i.e. if you have a pointer+keyboard
device, don't expose tapping configuration on the keyboard subdevice).
The result was messy, the checker function had a confusing triple-negation and
some properties weren't checked - e.g. left-handed was allowed for touch/tablet
but not for pointer, dwt was allowed for any device.
Fix this by moving the check into the property init function directly and
inverting the helper function to be easier to read.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not all clients update the pointer position correctly from the button events
(for historical reasons) so we need to send a motion event before the button
event that represents a tip state change.
https://bugs.freedesktop.org/show_bug.cgi?id=101588
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
