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>
Common problem: some touch sequence does something to confuse libinput but it
cannot easily be captureed. The result is a long sequence of touche that need
to be picked apart and isolated.
Print an easy-to-search for message in the evdev output that signals that the
device touch state is now neutral (i.e. no finger down). Same can be achieved
by searching for BTN_TOOL_FINGER but that provides false positives for
switching between one and two fingers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Collect libinput events together with the evdev events and print them to the
log. This makes it possible to debug the full behavior of a user's machine
rather than having to replay it with potential different race conditions/side
effects.
Example event output:
- evdev:
- [ 2, 314443, 4, 4, 57] # EV_MSC / MSC_SCAN 57
- [ 2, 314443, 1, 57, 1] # EV_KEY / KEY_SPACE 1
- [ 2, 314443, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +87ms
libinput:
- {time: 2.314443, type: KEYBOARD_KEY, key: 57, state: pressed}
- evdev:
- [ 2, 377203, 4, 4, 57] # EV_MSC / MSC_SCAN 57
- [ 2, 377203, 1, 57, 0] # EV_KEY / KEY_SPACE 0
- [ 2, 377203, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +63ms
libinput:
- {time: 2.377203, type: KEYBOARD_KEY, key: 57, state: released}
Note that the only way to know that events are within the same frame is to
check the timestamp. libinput keeps those intact which means we can tell that
if we just had an evdev frame with timestamp T and get a pointer motion with
timestamp T, that frame caused the motion event.
So far, only key, pointer and touch events are printed. We also
hardcode-enable tapping where available until we have options to enable this
on the commandline just because that's useful to have.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The stop variable set in the signal handler needs
volatile (and use the defined sig_atomic_t instead
of unsigned int).
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
