This is both a bug and required behavior. A caller may hold refcounted
references to devices, seats, or device groups but when libinput_unref()
cleans up, all these become invalid.
It is required behavior, because the last call to libinput_unref() also calls
libinput_suspend() and thus stops any events.
Any attempt at fixing this will break current behavior:
* keeping structs until all refcounts are 0 may leak memory in current
callers
* it would require an explicit call to libinput_suspend(), or make
libinput_unref() inconsistent in its behavior.
So we document it as a bug and tell people not to do it.
https://bugs.freedesktop.org/show_bug.cgi?id=91872
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The x230 has a special acceleration method that relies on the touchpad magic
slowdown. This was missing from commit c8da19b50a, making two-finger
scroll motions unusably fast
https://bugs.freedesktop.org/show_bug.cgi?id=91819
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
With this change auto assign events will be skipped if no replacement value
is provided. This behavior is practical when emitting mt events, as those
only contain the axis values that changed.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For short and quick scroll gestures, those that should only trigger a few
lines of scroll the pointer acceleration is wildly unpredictable. Since we
average the motion of both fingers it's hard enough to intuitively predict
what the motion will be like. On top of that is the small threshold before we
start scrolling, so some of the initial motion gets swallowed before we
accelerate, making the next motion even more unpredictable.
The end result is that multiple seemingly identical finger motions cause
wildly different scroll motion.
Drop pointer acceleration for two-finger and edge scrolling. This makes short
scroll motions much more predictable and doesn't seem to have much effect on
long scroll motions. Plus, in natural scroll mode it really feels like the
content is stuck to your fingers now. Go wash your hands.
https://bugzilla.redhat.com/show_bug.cgi?id=1249365
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For when we need to apply some transformation to the data but it shouldn't be
acceleration. Example use are touchpad coordinates, even when not
accelerating, we still want to apply the magic slowdown.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Requires splitting out the X230 one so we don't accidentally break things if
we ever change this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This test is supposed to test for the timeout kicking in on edge scrolling -
if the finger is in the edge for longer than the timeout, we switch to
scrolling without requiring the motion threshold to be met first.
To emulate this, move the finger ever so slightly first to load up the motion
history, then timeout, then move. We expect a bunch of motion events with a
small delta.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes the code more straightforward, and we now require the devices to
have a height/width anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Don't open-code the rate-limited log messages, use a simple wrapper instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A device with REL_X/Y and keys gets marked only as ID_INPUT_KEY, initializes
as keyboard and then segfaults when we send x/y coordinates - pointer
acceleration never initializes.
Ignore the events and log a bug instead. This intentionally only papers over
the underlying issue, let's wait for a real device to trigger this and then
look at the correct solution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is step one to fixing trackpoint acceleration, separating it from the
other acceleration code. No functional changes yet, it still uses the low-dpi
accel method.
https://bugs.freedesktop.org/show_bug.cgi?id=91369
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This is "once-tested, don't touch it again" code. The quirks on the touchpad
means we'd have to find that specific device again and re-test everything if
we change anything elsewhere in the code. So duplicate it properly, so that we
don't have to touch it again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Instead of going straight to pointer_notify_axis, go through
evdev_notify_axis() which flips the scroll direction around for us.
https://bugs.freedesktop.org/show_bug.cgi?id=91597
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous approach to pointer acceleration was to initialize the same
motion filter behavior but a different acceleration profile depending on the
hardware (the profile converts a speed to a multiplier for input deltas).
To be more flexible for hardware-specifics, change this into a set of specific
pointer acceleration init functions. This patch has no effective functional
changes, they're still all the same.
The acceleration functions are kept for direct access by the ptraccel-debug
tool.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
No functional changes, just moving code in preparation for filter patches
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
And switch to a code-flow that's a bit more self-explanatory than the current
min/max combinations.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This makes it more obvious where we're using units/us and units/ms as input
variable and what the output is. Clutters up the code, but still better than
dealing with us/ms differently per function, and still better than carrying
all the 1000.0 multiplications/divisions manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The return value of a profile is a unitless factor, not a speed.
Same applies for s1/s2, these are factors, not speeds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This reverts commit 8a6825f160.
Aside from introducing bugs, this doesn't really help with anything, it adds a
requirement to rename everything to make clear where we're using µs and where
we're using ms and that just clutters up the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
The previous code used a 5mm threshold before axis events were posted. This
threshold was on top of the 2mm 2fg threshold (and timeout handling) in the
gesture code and effectively prevented events from being sent after a timeout,
or in the 2mm-5mm range.
We still want a directional lock though, so split the two out. The default 5mm
threshold is set to 0 for touchpads since we have our own handling of the
threshold there. The directional lock only applies once scrollin has started
and remains on 5mm.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This will thus work if the property is only set on a parent device, not on the
device directly.
https://github.com/systemd/systemd/issues/763
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add arg --with-libunwind for configure so it's optional to check
libunwind, which is helpfull to make deterministic builds.
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The new values were in units/us and didn't make the switch back to ms in
8a6825f160.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
