- Oct 21, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
tap-tap-down-move should emit 1 click + press, not 2 clicks + press https://bugs.freedesktop.org/show_bug.cgi?id=92016 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit d92ae62d)
-
Peter Hutterer authored
The following sequence currently generates a right-button event: finger 1 down finger 2 down finger 1 up finger 2 held down This is easily triggered with short scroll events. There are two issues here: first is that the tapping code elsewhere treats any tap with a second finger down as a left-button tap, not a right button one. So if anything, we should generate a left button click here, not a right button click. Arguably, generating a button click here is wrong though, it's not a very well defined sequence and relatively difficult to trigger intentionally. So the best solution here is to simply ignore the release event and move straight back to state HOLD - unless the second finger is released within the timeout. If the finger is set down again during the timeout, we move straight to TOUCH_2_HOLD - this could eventually be interpreted as a tap, but not for now. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit 79570fd4)
-
- Sep 03, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
The x230 has a special acceleration method that relies on the touchpad magic slowdown. This was missing from commit c8da19b5, 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> (cherry picked from commit 6a0f9411)
-
- Aug 26, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Aug 23, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Aug 22, 2015
-
-
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Aug 21, 2015
-
-
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Aug 19, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
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
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>
-
- Aug 17, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Aug 16, 2015
-
-
Peter Hutterer authored
-
- Aug 12, 2015
-
-
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> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
- Aug 11, 2015
-
-
Peter Hutterer authored
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>
-
- Aug 10, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
Peter Hutterer authored
No functional changes. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-