My kingdome for a compiler warning. Or a scan-build warning. Or a coverity
warning. Or anything... But no, nothing.
Also make the open_restricted() more robust to a NULL userdata, because
effectively that's what we were passing here.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/50
Introduced in 0a13223c39
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The values are the same and this is ABI so they will never change. Make the
cast explicit for coverity's benefit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The &grab pointer we used to pass as userdata was the address of the function
argument which goes out of scope at the end of the function. This works fine
for devices immediately opened but when a device connects later, the address
may have been re-used since and it's content is undefined. If not NULL, we
end up grabbing the device.
Instead pass the grab option in which is guaranteed to live until the end of
main.
https://gitlab.freedesktop.org/libinput/libinput/issues/26
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All the tests fill fail anyway if the validation fails but this is a quick way
to fail everything early.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we had all extra device information ("This is an Apple Touchpad",
"This touchpad causes pointer jumps", etc.) in the udev hwdb. The problem with
the hwdb is that updating it is nontrivial for the average user and debugging
when things go wrong is even harder. Plus, the hwdb has a matching scheme that
is unpredictable unless one is familiar with the implementation.
This patch set moves the hwdb entries into .ini style text files, with a
simple line-based parser. A new libinput list-quirks tool can list the quirks
applied to any given device, in --verbose mode it prints all matches as they
apply or not apply.
The data files are currently unused by libinput, that comes in a later patch.
They're installed though, the defaults point to the /usr/share/libinput
directory and for *temporary* local overrides the single file
/etc/libinput/local-overrides.quirks.
Failure to parse any file is a hard failure for the quirks system, but if the
local override file doesn't exist that's fine.
THIS IS NOT A CONFIGURATION INTERFACE! None of these settings are exposed via
the libinput_device_config_* calls. There is no API guarantee for these files,
think of them as source code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput-measure-trackpoint-range doesn't work well for ALPS
touchsticks that have minimum delta amplitude of ~8. Fix that
by analyzing min and max amplitude (radius) of the measured deltas,
and suggesting a high trackpoint range value if ALPS-typical behavior
is encountered. Also, suggest a different calibration procedure
to the user; rather then just calibrating quick movements, slow, gentle
movements should also be covered.
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Found by scan-build, running ptraccel-debug --mode=sequence --nevents=5
would use garbage custom_deltas.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes the dead code issue introduced in
822c97a1c2, print_accel was always
true so the rest of the code never got triggered.
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>
We're printing most of those those as mm/s now, improve to use gnuplot for
loops, and a few other fixes. The low-dpi graph is still out of whack (or the
implementation is?), need to fix that separately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is virtually the only one that matters at this point, the others may help
but they're usually more confusing than helpful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leftover from a previous version where printing and handling an event was
identical. Now we may handle events but not actually print them until a bit
later, so other events may have a (wrong) zero timestamp.
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>
Partial fix only because we can't guess the build dir, but at least it doesn't
complain about the missing script now. And no-one really needs to run this
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is generated by the kernel's autorepeat code, see input_repeat_key() in
drivers/input/input.c
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
