- Apr 11, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Supposed to be [-1, 1] but we only generated [0, 1] Reported-by: Carlos Garnacho <carlosg@gnome.org> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Carlos Garnacho <carlosg@gnome.org> (cherry picked from commit 25a9f394)
-
We just returned the current profile instead of the default one. Fix that. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit ee6501d1)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit f44de7cc)
-
- Apr 06, 2016
-
-
Signed-off-by: Eric Engestrom <eric@engestrom.ch> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 7a81ba9c)
-
Peter Hutterer authored
Because our delta calculation factors in previous events on touchpads (to reduce jitter) we may get a nonzero delta if we have an event that doesn't actually change x or y. Drop the t->dirty workaround introduced in a608d9dc, an event that virtually disappears can mess up our state machines. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit bc17185f)
-
Peter Hutterer authored
The previous code would swap the top software buttons depending on the touchpad's left-handed setting, not the trackpoint setting. Changing both devices to left-handed resulted in a double-swap, i.e. the trackpoint was always right-handed. https://bugs.freedesktop.org/show_bug.cgi?id=94733 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit 1ecf6d7a)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 455498e9)
-
- Mar 15, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Mar 11, 2016
-
-
Peter Hutterer authored
The touchpad's sensors are too far apart (or the firmware interferes), causing in a jerky movement visible especially on slow motion. We get a bunch of normal motion events, then only ABS_MT_PRESSURE updates without x/y updates. After about one mm of movement x/y updates resume, with the first event covering the distance between the last motion event. That event is usually accelerated and thus causes a large jump. Subsequent events are sufficiently fine-grained again. This patch counts the number of non-motion events. Once we hit 10 in a row, we mark the first motion update as non-dirty, effectively discarding the motion and thus stopping the pointer jumps. https://bugs.freedesktop.org/show_bug.cgi?id=94379 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
-
- Mar 07, 2016
-
-
Peter Hutterer authored
The HUION 580 has a "consumer control" event node that has an ABS_VOLUME, keys and a REL_HWHEEL. It has the same VID/PID as the pen tablet and libwacom labels it as ID_INPUT_TABLET. This causes a crash later when we try to init pointer acceleration for a device that doesn't have axes. https://bugzilla.redhat.com/show_bug.cgi?id=1314955 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Had this in a private bug report recently. Missing hooks for open/close just segfault with little information to debug. Add an assert, this is definitely a bug in the caller and we don't need to recover from that. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Mar 02, 2016
-
-
Peter Hutterer authored
One test for an actual file (so far we only tested /tmp, the directory) and one for a kernel dev that returns a udev device and thus gets one step further in the error handling code. Plus, I saw test code doing this (opening /dev/uinput) and it crashed (for other reasons), so we might as well test it. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Mar 01, 2016
-
-
Peter Hutterer authored
We have a struct, use it. Better than passing arrays and array lengths around. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 28, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
If the fingers are vertically apart by more than 20mm we used to assume a pinch gesture immediately. This is too close together for some users during two-finger scrolling. Since we should always bias towards scrolling, only trigger this detection for three fingers, the rest has to go through the movement detection. The reason for the pinch detection here was to differentiate from 3fg swipe gestures (83f3dbd1), hence we're still in spirit of that patch. https://bugs.freedesktop.org/show_bug.cgi?id=94264 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Tested-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Feb 23, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
A nonzero resolution on the tilt axes is units/rad so we can calculate the physical min/max based. Uneven min/max ranges are supported. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
-
- Feb 18, 2016
-
-
Peter Hutterer authored
We previously used the half-way mark of the touchpad's y axis to decide where to ignore tapping. Move this down to the top edge of the software buttons instead. Users may tap with a finger in the software button areas, on the rest of the touchpad it's unlikely that they tap within 5% of the edge. On touchpads with physical buttons or if clickfinger is enabled, the no-tapping zone extends to the bottom of the touchpad. This required splitting the tests into clickfinger, softbuttons and hardbuttons. https://bugs.freedesktop.org/show_bug.cgi?id=93947 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Feb 17, 2016
-
-
Peter Hutterer authored
https://bugs.freedesktop.org/show_bug.cgi?id=94097 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Feb 15, 2016
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 11, 2016
-
-
Peter Hutterer authored
The newer Cintiqs have a minimum value of 400/400 advertised by the kernel but the actual sensor goes past the 0/0 origin. Test this, make sure that a value outside the boundaries generates negative mm values. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
One test now gets close enough to 100% of the axis value that ck_assert_double_lt() is not fine-grained enough. Switch to a direct x < 100.0 check. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 10, 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>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Should be offset by 180 degrees Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
No functional change. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
If the tablet is already in proximity on startup, we used to immediately sent a proximity event. We can't fetch MSC_SERIAL from the kernel, so that tool always had a serial of 0, followed by events with the real serial. Since clients are supposed to use the serial for the tracking of tools, this is suboptimal. When the tablet is added, merely set the internal proximity flags. This way we wait until the first real event from the device (which includes the serial number) and convert that into a proximity event. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 09, 2016
-
-
Peter Hutterer authored
https://bugs.freedesktop.org/show_bug.cgi?id=90590 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
The firmware version is in id.version, not id.model which is always PSMOUSE_ALPS for ALPS devices. The various fw versions are listed in <kernel>/drivers/input/mouse/alps.h and are all hex numbers. Version 8 is actually 0x800, change the match accordingly. Expected side-effect: earlier versions of ALPS touchpads now lose their (erroneous) size assignment. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
The Wacom tilt range is 64 degrees so we map everything into that until we know otherwise. This commit also switches the tilt axes around to align the angles with the x/y orientation, i.e. tilting the top of the stylus towards the positive x axis now generates a positive x tilt. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
-
- Feb 08, 2016
-
-
Peter Hutterer authored
If dwt is disabled on the commandline, e.g. by setting an xinput property it may be disabled before the release event comes in. This caused the timer to refresh indefinitely since the key state mask was still on for that key. Always updating the key state mask (even when dwt is disabled) fixes that. If a key is held down while dwt is disabled, this can still cause a indefinite timer refresh, so in the timer func, check if dwt is enabled before refreshing the timer. https://bugs.freedesktop.org/show_bug.cgi?id=94015 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Feb 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>
-
- Feb 04, 2016
-
-
Peter Hutterer authored
If a USB keyboard like the YubiKey is found before the internal keyboard, it will be paired with the touchpad when it is seen. The internal keyboard is seen later bug ignored because we already have a keyboard paired with the touchpad. This is obviously wrong. For now, give priority to serio keyboards, and override existing dwt pairings with the new keyboard. https://bugs.freedesktop.org/show_bug.cgi?id=93983 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
If a key enables dwt and is held down when the timeout expires, re-issue the timeout. There is a corner case where dwt may not work as expected: 1. key down and held down 2. dwt timer expires, dwt is re-issued 3. touch starts 4. key is released 5. dwt timer expires 6. touch now starts moving the pointer This is an effect of the smart touch detection. A touch starting after the last key press is released for pointer motion once dwt turns off again. This is what happens in the above case, the dwt timer expiring is the last virtual key press. This is a corner case and likely hard to trigger by a real user. https://bugs.freedesktop.org/show_bug.cgi?id=93984 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-