Add a boolean option/property to enable/disable the scroll button lock. Where
enabled, the button can be clicked and released as opposed to having to be
held down.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This merely tests against the devel package in Fedora, not against the xserver
from git. Should be enough, the driver here doesn't change enough to need the
git builds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This bumps the required libinput version to 1.7 - which has been out for over
two years now. That's conservative enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was part of the high-resolution wheel work that was factored out ahead of
time. Problem is: this breaks scroll button emulation in the server as we
use the distance to determine when we click buttons 4-7.
Before: movement of 15 normalized pixel units on a touchpad - one click. Now:
120 of those units. So that's a bit less than ideal.
The change to 120 can be done, but needs the corresponding handling in the
axis distance calculations.
Fixes#24
This reverts commit 055481187d.
On devices with tools having both serial and id 0,
it would fail to create separate subdevices.
Thinkpad X220T (Wacom ISDv4 E6) now correctly registers
Pen and Eraser xinput devices.
This is just a number, to be used as divider and shouldn't have any effect in
correctly written clients. With the high-res scrolling coming up however, we
have a few devices where the dist cannot be expressed as an integer fraction
of 15, so let's up it to 120 because we know all hardware wheels have to be an
integer fraction of that that, thanks to Microsoft's API requirements.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The driver currently assumes that any wheel event has a non-zero discrete
value of 1. This is incorrect, it just hasn't triggered yet with any device.
With the hi-res scroll patches in place in the kernel and libinput, we may get
wheel events with a discrete value of 0. We assume that if this ever happens,
the device has some sensible click angle set so all we need to do is ignore
the discrete 0 events and wait for the first discrete event to come.
Also add an explanatory comment too to make it clear the calculation is only
done once.
Fixes#19
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is prep work for the hi-res work but right now, no real functional
changes. It does however fix a bug where we used the vertial scroll dist for
the horizontal wheel as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Users still like to copy the whole file, potentially messing things up.
Let's put a warning into the file directly that this is less than ideal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Custom pointer acceleration curves were reverted in libinput, so no point
having this code here.
This reverts commit d84e0035d1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
One new property, and the existing accel profile gets extended to keep one
extra value. The new property libinput Accel Curve Points is a list of pairs
of points to be added to the acceleration curve.
libinput only supports adding points to the curve so we simply declare the
behavior as undefined when the curve is set multiple times. Also helps to
identify those that bother to read the man page before playing with random
driver values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
