1. 23 Mar, 2018 11 commits
  2. 21 Mar, 2018 3 commits
  3. 20 Mar, 2018 4 commits
  4. 19 Mar, 2018 3 commits
    • Peter Hutterer's avatar
      tools: libinput-record: print a progress bar when recording to a file · a1ba6186
      Peter Hutterer authored
      To let users know something is happening.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      tools: libinput-record: print a comment when the device is in a neutral state · 056a5eb6
      Peter Hutterer authored
      Common problem: some touch sequence does something to confuse libinput but it
      cannot easily be captureed. The result is a long sequence of touche that need
      to be picked apart and isolated.
      Print an easy-to-search  for message in the evdev output that signals that the
      device touch state is now neutral (i.e. no finger down). Same can be achieved
      by searching for BTN_TOOL_FINGER but that provides false positives for
      switching between one and two fingers.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      tools: libinput-record: add support for printing libinput events · 6e4c8363
      Peter Hutterer authored
      Collect libinput events together with the evdev events and print them to the
      log. This makes it possible to debug the full behavior of a user's machine
      rather than having to replay it with potential different race conditions/side
      Example event output:
        - evdev:
          - [  2, 314443,   4,   4,    57] # EV_MSC / MSC_SCAN               57
          - [  2, 314443,   1,  57,     1] # EV_KEY / KEY_SPACE               1
          - [  2, 314443,   0,   0,     0] # ------------ SYN_REPORT (0) ---------- +87ms
          - {time: 2.314443, type: KEYBOARD_KEY, key: 57, state: pressed}
        - evdev:
          - [  2, 377203,   4,   4,    57] # EV_MSC / MSC_SCAN               57
          - [  2, 377203,   1,  57,     0] # EV_KEY / KEY_SPACE               0
          - [  2, 377203,   0,   0,     0] # ------------ SYN_REPORT (0) ---------- +63ms
          - {time: 2.377203, type: KEYBOARD_KEY, key: 57, state: released}
      Note that the only way to know that events are within the same frame is to
      check the timestamp. libinput keeps those intact which means we can tell that
      if we just had an evdev frame with timestamp T and get a pointer motion with
      timestamp T, that frame caused the motion event.
      So far, only key, pointer and touch events are printed. We also
      hardcode-enable tapping where available until we have options to enable this
      on the commandline just because that's useful to have.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  5. 15 Mar, 2018 1 commit
  6. 14 Mar, 2018 1 commit
  7. 13 Mar, 2018 3 commits
  8. 12 Mar, 2018 1 commit
  9. 09 Mar, 2018 5 commits
  10. 08 Mar, 2018 4 commits
    • Peter Hutterer's avatar
      Extract and reset the abs fuzz value for the x/y axes · 1523d8bb
      Peter Hutterer authored
      The kernel fuzz handling is buggy, especially when we want to rely on the fuzz
      value for our hysteresis. But since this is a hw property and (at least
      sometimes) set by the driver, we can't make this a pure libinput hwdb set
      So our workaround is:
      * extract the (non-zero) fuzz into a udev property so we don't lose it
      * set the fuzz to 0 to disable the in-kernel hysteresis
      * overwrite our internal absinfo with the property fuzz
      This way we get to use the hw-specified fuzz without having the kernel muck
      around with it. We also get to use the EVDEV_ABS_ values in 60-evdev.hwdb to
      override a driver-set fuzz.
      Two drawbacks:
      - we're resetting the kernel fuzz to 0, this affects any other users of the
        device node. That's probably a minor impact only.
      - we can only save this in a udev property there's a risk of this information
        getting lost when playing around with udev rules. That too should be a minor
      https://bugs.freedesktop.org/show_bug.cgi?id=105303Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      touchpad: enable hysteresis based on a 0 fuzz value · 1b64888a
      Peter Hutterer authored
      If the fuzz is 0, assume we don't need hysteresis and use the wobble detection
      code instead. If the fuzz is non-zero, enable it by default.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      touchpad: use the fuzz value (if any) for the hysteresis margin · ea7498ef
      Peter Hutterer authored
      We currently used 0.5mm on touchpads as hysteresis value. This causes pointer
      movement delays, it is likely too high. Reduce it to a kernel-set fuzz value
      (if any) and see how we go with that. On many touchpads, the fuzz is 8 which
      would be closer to 0.2mm on e.g. a T440.
      Note that the does some defuzzing anyway, but the response of that function is
      nonlinear, e.g. for a fuzz of 8, the physical deltas map to:
      phys 0..3  → delta 0
      phys 4..7  → delta 1
      phys 8..15 → delta 4, 5, 6, 7
      phys 16..N → delta 16..N
      In other words, we never see some logical deltas 2 and 3. While this shouldn't
      matter given the average touchpad resolution, reducing the hysteresis margin
      is likely to provide some better response. We never see values 8-15 either
      which could be the cause of some pointer jumps we've been seeing.
      see https://bugs.freedesktop.org/show_bug.cgi?id=105303
      Devices with a fuzz of 0 have the hysteresis margin reduced to 0.25mm (from
      https://bugs.freedesktop.org/show_bug.cgi?id=105108Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      fallback: fix touchscreen defuzzing · 50418a01
      Peter Hutterer authored
      The hysteresis-returned point always differs from the current point, even if
      the hysteresis kicks in. We need to compare to the hysteresis center.
      And the returned point is only the new center if we exceed the margin,
      otherwise the center stays as-is.
      The touch_fuzz() test only succeeded for this because for the values we were
      introducing jitter by, the kernel filtered out all the actual movement so
      these paths weren't hit.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  11. 07 Mar, 2018 3 commits
  12. 06 Mar, 2018 1 commit