- Dec 08, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Dec 07, 2015
-
-
Peter Hutterer authored
Once we trigger diagonal scrolling, the device's scroll direction is set as horiz+vert. From then on, both axes will be set on every subsequent scroll event, even when the actual delta for an axis is 0. This causes continuous scroll stop events in clients that care about these things. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
We dont' want to fill up the event queue and cause SYN_DROPPED events. 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>
-
- Dec 02, 2015
-
-
Peter Hutterer authored
If all fingers are released in the same frame, we won't be able to find the top-most touch. https://bugs.freedesktop.org/show_bug.cgi?id=93204 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
If the test is filtered out and we never run it generates a false positive. Though it isn't listed in the "Checks" summary this is a bit hard to tell when you're running >700 tests. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
These aren't real button events and they are handled elsewhere, either through proper touch events on touchscreen or through custom handling in the touchpad case. https://bugs.freedesktop.org/show_bug.cgi?id=93165 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>
-
- Nov 15, 2015
-
-
Peter Hutterer authored
At least on the t440, this is enough to trigger correct detection between pinch and scroll 90% of the time. Since scrolling is significantly more prevalent than gesturing, erring on the side of scrolling at the cost of misdetecting some gestures is acceptable. 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
And link the software buttons sentence to the t440 page. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 09, 2015
-
-
Peter Hutterer authored
Otherwise events that are already queued before the first libinput_dispatch() have a negative timestamp. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
There were two files (doc/svg/{edge,twofinger}-scrolling.svg) that had both arrow heads pointing to wrong direction. Those arrow heads used markers but their ids were defined wrong and therefore they displayed weirdly. On Firefox the arrow head that should have pointed to left pointed actually to right. This commit fixes that problem by defining the marker ids correctly. I tested on Firefox 40.0.3 that the arrow heads are now displayed correctly. Reviewed-by: Bryce Harrington <bryce@osg.samsung.com> Tested-by: Bryce Harrington <bryce@osg.samsung.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 01, 2015
-
-
Peter Hutterer authored
struct list isn't a null-terminated list, list_for_each() causes 'g' to be set to the list head at the end of the loop. Returning that as group caused random memory to be overwritten. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Oct 30, 2015
-
-
Peter Hutterer authored
The Asus RoG Gladius exposes two event nodes, one mouse, one keyboard. The keyboard node has REL_X/Y and REL_HWHEEL on top of the various key bits and ABS_VOLUME. The keyboard node does not have BTN_* set, udev tags this device as a keyboard only, not as a pointer but we still initialize the pointer caps for it because of the wheel. When moving this mouse, some deltas (ca "1 in every 20") are sent through the keyboard node, causing a crash because we never initialized pointer acceleration. https://bugzilla.redhat.com/show_bug.cgi?id=1275407 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Oct 28, 2015
-
-
Peter Hutterer authored
This check is already in place for all other event types. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
And use the unaccelerated motion events. Better than crashing, and better than a non-moving mouse. 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>
-
- Oct 26, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Sep 18, 2015
-
-
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>
-
- Sep 10, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
The quartett of new config functions is: libinput_device_config_accel_get_profiles libinput_device_config_accel_get_profile libinput_device_config_accel_set_profile libinput_device_config_accel_get_default_profile The profile defines how the pointer acceleration works, from a very high-level perspective. Two profiles are on offer, "adaptive", the standard one we have used so far and "flat" which is a simple multiplier of input deltas and provides 1:1 mapping of device movement vs pointer movement. The speed setting is on top of the profile, a speed of 0 (default) is the equivalent to "no pointer acceleration". This is popular among gamers and users of switchable-dpi mice. The flat profile unnormalizes the deltas, i.e. you get what the device does and any device below 800dpi will feel excruciatingly slow. The speed range [-1, 1] maps into 0-200% of the speed. At 200%, a delta of 1 is translated into a 2 pixel movement, anything higher makes it rather pointless. The flat profile is currently available for all pointer devices but touchpads. https://bugs.freedesktop.org/show_bug.cgi?id=89485 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Sep 09, 2015
-
-
Peter Hutterer authored
If a caller has a reference to a device group when the context is destroyed, the memory for the group is never released. Calling libinput_device_group_unref() will release it and there are no side-effects since the group has no back-references. It's inconsistent with the rest of libinput though - all other resources get released on libinput_unref(). Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
-
- Sep 07, 2015
-
-
Peter Hutterer authored
This was accidentally disabled in 6953b51b. We want to fail when a bug is exposed. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Sep 06, 2015
-
-
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>
-
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Sep 04, 2015
-
-
Peter Hutterer authored
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>
-
- Aug 31, 2015
-
-
Peter Hutterer authored
https://bugs.freedesktop.org/show_bug.cgi?id=91563 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
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>
-
- Aug 26, 2015
-
-
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>
-
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>
-