- Feb 13, 2018
-
-
Peter Hutterer authored
-
- Feb 09, 2018
-
-
Peter Hutterer authored
Rotation on a tool can either ABS_Z or in the case of the mouse/lens tools a combination of ABS_TILT_X/Y. The code assumes that if the rotation on a stylus (not mouse/lense) changes, we need to fetch it from ABS_Z. This happens on the very first event from the tablet, proximity in invalidates all axes so we can send the current state to the caller. On libwacom-recognized tablets we never set the rotation bit on the stylus, so that's all fine. On tablets without libwacom support, the stylus may have a rotation bit copied because we have it set thanks to mouse+tilt on the tablet. When that first event is handled, we try to access ABS_Z. On tablets without ABS_Z like Aipteks, we go boom. Fix this by checking for ABS_Z during tablet init, if we don't have that axis then never set the rotation bit on the tool. That's the only axis where we need this, all other axes have a single cause only and thus the tablet bits are accurate anyway. https://bugs.freedesktop.org/show_bug.cgi?id=104939 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 07, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
We filter BTN_TOUCH in the caller, so this cannot happen here. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
We fall through to the default statement anyway Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 06, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
This looks like a libinput bug (well, it does say "libinput bug" on the package) but it hasn't been that for a long time. The cause is almost always insufficient motivation to call libinput_dispatch() by the caller, or at least not doing it with the celerity libinput demands (and deserves, if I may say so). Up-, down- or side-grade it to a client bug, so the outrage can be directed elsewhere, preferably away from me. And add a section to the documentation, just in case someone actually reads this stuff. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
-
Peter Hutterer authored
So we don't have to have newline handling in the callers. This effectively reverts 6ab2999b "test: detect linebreaks in log messages". https://bugs.freedesktop.org/show_bug.cgi?id=104957 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
- Feb 05, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
If there's anything that listens for KEY_POWER it will likely shut down or suspend the host. Since it doesn't matter whether we're really testing for KEY_POWER or just any other key, let's just switch it and avoid one headache. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 01, 2018
-
-
Peter Hutterer authored
Too easy to trigger with the short button debouncing offsets Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Having the system suspend or shutdown halfway through a test run is a tad annoying. So let's talk to logind and tell it to inhibit the various keys we're testing. https://bugs.freedesktop.org/show_bug.cgi?id=104720 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jan 23, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jan 21, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jan 18, 2018
-
-
Peter Hutterer authored
17.04 is EOL, and this means we can drop our meson-from-build section too Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
This broke with meson 0.44 and results in an error: RuntimeError: Could not determine how to run Meson. Please file a bug with details. See https://github.com/mesonbuild/meson/issues/2761 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jan 10, 2018
-
-
Peter Hutterer authored
Previously, touchpad deltas were converted to 1000-dpi normalized coordinates and handled from there. This changed in bdd4264d (1.6) when the filter functions started taking device coordinates instead. Since then, we used to convert the device delta to normalized coordinates, then (often immediately) convert back to device coordinates, albeit for equal x/y resolution. This isn't necessary, we can just convert the device coordinates to x/y-equal resolution device coordinates and pass those on. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jan 09, 2018
-
-
Peter Hutterer authored
On the very first event, the last_motion_time set by tp_begin_touch is not yet set because we are called before the pressure-based touch detection takes effect. And any event timestamp is more than 80ms after a zero timestamp, causing the hysteresis to always be disabled. https://bugs.freedesktop.org/show_bug.cgi?id=98839#c74 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
2000ms should be enough, if that fails let's bail completely. Related to: https://bugs.freedesktop.org/show_bug.cgi?id=104278 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
When running the test suite in full fork mode, the error messages are in the quite verbose output and searching for them is annoying. Work around this by opening a pipe to each subprocess and writing the failed test cases to that pipe. When all tests have finished, print the messages to stdout. This way the failures are always the last thing printed by the test suite. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Dec 18, 2017
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
This was never true, we for the first part 3 lines above and return early. So if we get here, it's always false. commit aa87d2b2 added the new condition above, so since then this code was inactive and can be removed. https://bugs.freedesktop.org/show_bug.cgi?id=104279 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Dec 08, 2017
-
-
Peter Hutterer authored
Some pens keep sending small amounts of pressure even when the tip is up. This isn't always a sign of the pens worn out, it also happens on the new Pro Pen 3D models. The X driver uses a default threshould of ~1.3% to paper over this, let's do the same with a 1% threshold. This threshold only applies to pens that don't already have a pressure offset anyway. https://bugs.freedesktop.org/show_bug.cgi?id=103086 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Commit db3b6fe5 "fallback: change to handle the state at EV_SYN time" introduced regressions for two types of event sequences. One is a kernel bug - some devices/drivers like the asus-wireless send a key press + release within the same event frame which now cancels out and disappears into the ether. This should be fixed in the kernel drivers but there appear to be enough of them that we can't just pretend it's an outlier. The second issue is a libinput bug. If we get two key events in the same frame (e.g. shift + A) we update the state correctly but the events are sent in the order of the event codes. KEY_A sorts before KEY_LEFTSHIFT and our shift + A becomes A + shift. Fix this by treating key events as before db3b6fe5 - by sending them out as we get them. https://bugs.freedesktop.org/show_bug.cgi?id=104030 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 30, 2017
-
-
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Almost everything requires libudev because libinput.h pulls it in. Make this an explicit dependency. 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>
-
- Nov 29, 2017
-
-
Peter Hutterer authored
Suggested in https://bugs.freedesktop.org/show_bug.cgi?id=103947#c2 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
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 27, 2017
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 21, 2017
-
-
Peter Hutterer authored
Sequences to trigger: - spurious debouncing is enabled - release a button in IS_DOWN state -> RELEASE_DELAYED - short timeout triggers RELEASE_WAITING If a button press now comes before the long timeout expires, we transition to MAYBE_SPURIOUS where the long timeout may expire. In that case we should transition to pressed state again. Reported-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 20, 2017
-
-
Peter Hutterer authored
Unlike the already-existing thumb detection, a touch may be labelled palm at any time, not just during the initial touch down. This requires full integration into the tap state machine to unwind properly. For most states, a palm detection simply ignores the finger and reverts to the most recent state. One exception is the case of two fingers down, one finger up followed by the remaining finger detected as a palm finger. This triggers a single-finger tap but with timestamps that may be from the wrong finger. Since we're within a short tap timeout anyway this should not matter too much. The special state PALM_UP is only handled in one condition (DEAD). Once a touch is a palm we basically skip over it from then on. If we end up in the DEAD state after a button press we still need to handle the palm up events accordingly to be able to return to IDLE. That transition also requires us to have an accurate count of the real fingers down (palms don't count) so we need a separate nfingers_down counter for tapping. https://bugs.freedesktop.org/show_bug.cgi?id=103210 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Same thing under the hood but still... Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
8cf6893f removed it to make search/replace easier, restore it for the tests where we don't want debouncing to automatically be handled. Still left in place are the various top software button cases. Because of the button re-routing through the fallback interface we need those to be debounced. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-