This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity screwed up something so we can't submit builds right now, the
compilation units all fail. math.h pulls in a _Float128 type that coverity
cannot handle. So as a workaround, add an option to the build to avoid this
and remove it when the next version of coverity hopefully fixes this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Well, I say "measure" but really at this point it just reads the
properties/axes and then does it's best to auto-generate a hwdb entry that
matches the user's hardware and sets a fuzz value on the device. Ideally this
reduces the number of hand-holding required in bugzillas. There are plenty of
things that can go wrong, so our fallback is still to throw up our hands and
point to the documentation.
https://bugs.freedesktop.org/show_bug.cgi?id=98839
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses" and whatnot (some notable exceptions in e.g. bug 101139).
Attempts to change the actual acceleration function will likely break things
for others.
This approach opens up the profile itself to a user-specific acceleration
curve. A caller can set an acceleration curve by defining a number of points
on that curve to map input speed to an output factor. That factor is applied
to the input delta.
libinput does relatively little besides mapping the deltas to the
device-specific speed, querying the curve for that speed and applying that
factor. The curve is device-specific, the input speed is in device units/ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Plenty of duplication there from the normal filter.c, but that also makes it
less likely to break if we adjust the other one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This also fixes a bug with the _noop function, because we casted to the wrong
struct the dpi value was garbage.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's a fair bit of duplication of code from filter.c but it's not worth
disecting this and optimising it. The device is 5 years old now, we don't want
to touch this accel method so duplication is good here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
An aborted test run can sometimes leave udev rules as detritus. Test for that
so we don't get test case failures triggered by those rules.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Especially dot is hard to find for some users, so provide the solution to
their problems right there in the error message.
And because users are likely to just copy/paste, remove the disable-libwacom
option. Save them from themselves...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel fuzz handling is buggy, especially when we want to rely on the fuzz
value for our hysteresis. But since this is a hw property and (at least
sometimes) set by the driver, we can't make this a pure libinput hwdb set
either.
So our workaround is:
* extract the (non-zero) fuzz into a udev property so we don't lose it
* set the fuzz to 0 to disable the in-kernel hysteresis
* overwrite our internal absinfo with the property fuzz
This way we get to use the hw-specified fuzz without having the kernel muck
around with it. We also get to use the EVDEV_ABS_ values in 60-evdev.hwdb to
override a driver-set fuzz.
Two drawbacks:
- we're resetting the kernel fuzz to 0, this affects any other users of the
device node. That's probably a minor impact only.
- we can only save this in a udev property there's a risk of this information
getting lost when playing around with udev rules. That too should be a minor
issue.
https://bugs.freedesktop.org/show_bug.cgi?id=105303
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only the ones we care about in libinput but for those it's handy to know which
ones are set (especially the LIBINPUT_MODEL ones).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This needs to be specified as keyword argument, and meson < 0.41 doesn't allow
for a missing fallback.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes the dependency chain, otherwise a race condition between building
libinput-record and building the git version header causes random build
failures.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some of wacom's tablets, notably the Bamboo series, have a non-predictable
scheme of mapping the buttons to numeric button numbers in libwacom. Since we
promise sequential button numbers, we need to have those identical to
libwacom, otherwise it's impossible to map the two together.
Most tablets have a predictable mapping, so this does not affect the majority
of devices.
For the old-style bamboos, this swaps the buttons around with the buttons
being ordered vertically top-to-bottom in libwacom.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Similar in style to evemu-play but parses the YAML printed by
libinput-record. Note that this tool requires python-libevdev which is a new
package and may not be packaged by your distribution. Install with pip3 or
alternatively, just ignore libinput-replay, it's a developer tool only anyway.
User-visible differences to evemu-play:
* supports replaying multiple devices at the same time.
* no replaying on a specific device, we can add this if we ever need it
* --verbose prints the event to stdout as we are replaying them. This is
particularly useful on long recordings - once the bug occurs we can ctrl+c
and match up the last few lines with the recordings file. This allows us to
e.g. drop the rest of the file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a tool that does effectively the same job as evemu-record.
evemu has two disadvantages: its API is clunky and hard to extend even for
simple features. And it has a custom file format that requires special
processing but is difficult to extend and hard to write manually. e.g. the
bitmasks require keeping a line number state to know which bit an entry refers
to.
libinput-record records the same data but the output is YAML. That can be
processed easier and extended in the future without breaking the parsing. We
can (in the future) also interleave the evemu output with libinput's debug
output, thus having a single file where the events can be compared and
analysed without the need for replaying. Likewise, we can easily annotate the
file with parsable bits of information without having to shove all that into a
comment (like version numbers of libinput, kernel, etc).
User-visible differences to evemu-record:
* the output file requires an explicit -o or --output-file argument
* no evemu-describe equivalent, if you just want the description simply cancel
before any events are sent
* to see key codes, a --show-keycodes flag must be supplied, otherwise all
'normal' keys end up as KEY_A. This protects against inadvertent information
leakage
* supports a --multiple option to record multiple devices simultaneously. All
recordings have the same time offset, it is thus possible to reproduce bugs
that depend on the interaction of more than one device.
And to answer the question of: why a printf-approach to writing out yaml
instead of a library, it's simply that we want to be able to have real-time
output of the recording.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If libdir is an absolute path (which means it’s outside of prefix) we
would wrongly add the prefix to it in the install script. Just pass the
correct libdir from Meson directly thanks to join_paths() magic.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since the install script cannot know the correct bindir, just pass it
from Meson directly.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A set of wireless devices that can scramble the timestamps, so we get
press/release within 8ms even though I doubt the user is capable of doing
this. Since they're generally good quality anyway, let's just disable
debouncing on those until someone complains and we need something more
sophisticated.
https://bugs.freedesktop.org/show_bug.cgi?id=104415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having the system suspend or shutdown halfway through a test run is a tad
annoying. So let's talk to logind and tell it to inhibit the various keys
we're testing.
https://bugs.freedesktop.org/show_bug.cgi?id=104720
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Almost everything requires libudev because libinput.h pulls it in. Make this
an explicit dependency.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current debouncing code monitors events and switches on when events are
too close together. From then on, any event can be delayed.
Vicente Bergas provided an algorithm that avoids most of these delays:
on a button state change we now forward the change without delay but start a
timer. If the button changes state during that timer, the changes are
ignored. On timer expiry, events are sent to match the hardware state
with the client's view of the device. This is only done if needed.
Thus, a press-release sequence of: PRP sends a single press event, a sequence of
PRPR sends press and then the release at the end of the timeout. The timeout
is short enough that the delay should not be noticeable.
This new mode is called the 'bounce' mode. The old mode is now referred to as
'spurious' mode and only covers the case of a button held down that loses
contact. It works as before, monitoring a button for these spurious contact
losses and switching on. When on, button release events are delayed as before.
The whole button debouncing moves to a state machine which makes debugging a
lot easier. See the accompanying SVG for the diagram.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A lot easier to process data in python than in C.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Dima Ryazanov <dima@gmail.com>
Tested-By: Dima Ryazanov <dima@gmail.com>
