- 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>
-
Peter Hutterer authored
-
- Nov 19, 2017
-
-
Peter Hutterer authored
The current debouncing code monitors events and switches on when events are too close together. From then on, any event can be delayed. Vicente Bergas provided an algorithm that avoids most of these delays: on a button state change we now forward the change without delay but start a timer. If the button changes state during that timer, the changes are ignored. On timer expiry, events are sent to match the hardware state with the client's view of the device. This is only done if needed. Thus, a press-release sequence of: PRP sends a single press event, a sequence of PRPR sends press and then the release at the end of the timeout. The timeout is short enough that the delay should not be noticeable. This new mode is called the 'bounce' mode. The old mode is now referred to as 'spurious' mode and only covers the case of a button held down that loses contact. It works as before, monitoring a button for these spurious contact losses and switching on. When on, button release events are delayed as before. The whole button debouncing moves to a state machine which makes debugging a lot easier. See the accompanying SVG for the diagram. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
The previous approach was to remember the last event and flush it at the right time. The new approach is to update the device state during the frame and send out the events at EV_SYN time. This gives us two advantages: we are not dependent on the kernel order of how events come in and we can process events depending on other events in the same frame. This will come in handy later for button debouncing. This is also the approach we have in the touchpad and tablet backends. Two FIXMEs are left in place, the button debouncing code and the lid switch code. Both need to be handled in future patches. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
This one is present in the parent evdev device Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
So we can split up evdev-fallback.c into multiple files where needed. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
This is via a simple search & replace. Later auditing is needed to switch clicks that should not be debounced (e.g. touchpads) back to a non-debounced version. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 17, 2017
-
-
Peter Hutterer authored
Getting spurious test case failures in these two tests but they're not easily reproducible. One cause may be a slight delay of the event that we're writing to the kernel device. If that has a minor delay, we'll miss it. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 16, 2017
-
-
Peter Hutterer authored
A lot easier to process data in python than in C. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-By: Dima Ryazanov <dima@gmail.com> Tested-By: Dima Ryazanov <dima@gmail.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>
-
- Nov 15, 2017
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Nov 14, 2017
-
-
Peter Hutterer authored
The other tablet mode notices say "suspending ..." Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
From https://bugzilla.redhat.com/show_bug.cgi?id=1510814 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
vertical wheel is y, not x Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-