- Aug 30, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
We've already been doing this for semi-mt devices and for non-clickpads but let's do it for clickpads as well. On Synaptics touchpads (PS/2 and RMI4) we see slot jumps where two slots are active, slot X ends but slot Y continues with the other slot's positional data. This causes a cursor jump on finger lift after a two-finger scrolling motion. Simply resetting the motion history fixes it. The only multi-finger interaction where a user could expect perfect fluid motion is when using a second finger to touch cone of the software button areas. Let's see if we have complaints first before we implement something more complex. https://bugs.freedesktop.org/show_bug.cgi?id=91695 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit aa87d2b2)
-
Peter Hutterer authored
Probably a copied typo in the original tests, 5 events with 40ms in between makes less sense than the now-replacement 20 events every 2ms. The previous one could trigger the cursor jump detection. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit bc9e9267)
-
Peter Hutterer authored
If a touch was down (and up again) before the device was switched to edge scrolling, libinput reported an error message: litest error: libinput bug: unexpected scroll event 0 in area state While edge scrolling was disabled, any new touch would be set to the area state but it was never reset on touch release. https://bugs.freedesktop.org/show_bug.cgi?id=97425 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit b1a811ee)
-
Peter Hutterer authored
The only reason to have more than one finger on a non-clickpad is to tap, scroll or gesture. In all cases resetting the motion history is a good idea to avoid jumps moving from 2 to 1 finger. https://bugs.freedesktop.org/show_bug.cgi?id=97194 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit 3cb60130)
-
- Aug 18, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 60c8b076)
-
- Aug 05, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit ae30353a)
-
- Aug 04, 2016
-
-
Peter Hutterer authored
udev now labels touchpads as "internal" or "external" for us, use that value where available and only fall back onto our own labelling if it's missing or unknown. systemd commit: https://github.com/systemd/systemd/pull/3638 https://bugs.freedesktop.org/show_bug.cgi?id=96735 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 64e39411)
-
Peter Hutterer authored
These are the simplest examples on how to use libinput and should be enough to get any potential user started. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 14d0cd9d)
-
Peter Hutterer authored
In some cases a device may need a device group assigned by a custom udev rule or hwdb entry. Don't overwrite that with our generated one. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit 188bad48)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 45a574a7)
-
- Jul 18, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
The i2c one came from an Dell XPS13. The ALPS one I can't remember but highly likely they were on Dells and if not, nothing really changes here anyway because it's not a clickpad and right now only clickpads have dell-specific behaviour. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jul 17, 2016
-
-
Peter Hutterer authored
No functional changes, just makes the unit more explicit Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Jul 15, 2016
-
-
Peter Hutterer authored
We simply don't have enough space on those touchpads to have an area carved out for horizontal scrolling. Given that horizontal scrolling is rarely needed anyway users of these touchpads will just have to cling to scroll bars or use two-finger scrolling. Exception are small clickpads because they already have an area blocked off for software buttons and those small clickpads generally come from a time when clickfinger wasn't much of a thing yet. https://bugs.freedesktop.org/show_bug.cgi?id=96910 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Jul 14, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Jul 13, 2016
-
-
Peter Hutterer authored
All Dell touchpas appear to have a visual marker on their touchpads. With a visible marker our middle button can (and should) be much smaller since we can rely on users to hit the button precisely. https://bugs.freedesktop.org/show_bug.cgi?id=96710 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Tested-by: Andy Lutomirski <luto@kernel.org> Reviewed-by: Yong Bakos <ybakos@humanoriented.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jul 12, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jul 11, 2016
-
-
Peter Hutterer authored
Unimplemented and it wasn't supposed to be in the series. https://lists.freedesktop.org/archives/wayland-devel/2016-June/029376.html Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jul 05, 2016
-
-
Peter Hutterer authored
Otherwise we overwriting the output from the normal test run. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
10s is not enough when running the test suite in parallel as any test may have to wait longer than that to get access to the udev lock. Especially for tests with multiple timeouts it was too easy to trigger timeouts. Up the timeout to 30s, this seems reliable enough now. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
Peter Hutterer authored
litest_add_device and litest_delete_device trigger a udev rule reload. This messes with some test devices and when we run multiple tests in parallel we get weird errors like "keyboard $BLAH failed the touchpad sanity test". Still not 100% reliable to run tests in parallel, but it's vastly improved now. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
Peter Hutterer authored
If the first device we got didn't have the expected syspath we'd leak the device and cause the valgrind tests to fail. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jul 04, 2016
-
-
Peter Hutterer authored
-
- Jul 03, 2016
-
-
Peter Hutterer authored
Expose the middle button emulation on software buttons as proper config option. When enabled, remove the middle button software button area. https://bugs.freedesktop.org/show_bug.cgi?id=96663 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Middle button emulation may be delayed in turning on, but during that delay we already need to return the desired state. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
To unify this we need to move the tagging process forward so tp_init() can rely on it for config setup. This means moving it to the touchpad init code. Other than that no real functional changes, the rules stay the same: * serial/i2c/etc. are considered internal touchpads * Bluetooth is always external * USB is external for Logitech devices * USB is external for Wacom devices * USB is internal for Apple touchpads And if we can't figure it out, we assume it's external and log a message so we can put a quirk in place. https://bugs.freedesktop.org/show_bug.cgi?id=96735 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Increase the mm move threshold for 3 and 4 finger gestures to 2 and 3 mm, respectively. In multi-finger gestures it's common to have minor movement while all fingers are being put down or before the conscious movement starts. This can trigger invalid gesture detection (e.g. a pinch instead of a swipe). Increase the movement threshold to make sure we have sufficient input data. No changes to 2-finger movements. https://bugs.freedesktop.org/show_bug.cgi?id=96687 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Jun 30, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
I'm typing this way too often into bugreports Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jun 28, 2016
-
-
Peter Hutterer authored
A natural hand position for a 4-finger swipe will have one finger well below the other triggering the pinch detection. This is obviously wrong, only do the finger position analysis when we have 2 fingers. This is only a partial fix, for 3-4 finger gestures chances are high that the third/fourth finger come in a different event frame. Before that we likely detect 2 fingers in a possible pinch position and still trigger the code path. This issue has to be fixed separately. https://bugs.freedesktop.org/show_bug.cgi?id=96687 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
The current code tried to emulate the relative motion to be equivalent to the absolute motion, except in screen coordinates. This is way too slow for the cursor tool that we want to behave like a mouse. Tablets have high resolution (e.g. an Intuos 4 is a 5080dpi mouse) and that motion is way too fast to be usable. Scale it down to match a 1000dpi device instead. Since the cursor and lens tool are still high precision devices leave them in a flat acceleration profile without actual acceleration. For the stylus-like devices leave the current accel, pointer acceleration on a stylus is hard to handle. This also adds the missing bits for actually using the speed factor set through the config interface. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
-
- Jun 27, 2016
-
-
Peter Hutterer authored
The x/y tilt angle comes in as degrees, so our scale could be as large as 90x the original size. Scale to something more sensible. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-