1. 09 Apr, 2018 3 commits
  2. 06 Apr, 2018 1 commit
  3. 05 Apr, 2018 4 commits
  4. 04 Apr, 2018 1 commit
    • Nandor Han's avatar
      udev: validate input devices during cold-plug · 23d543b7
      Nandor Han authored
      During libinput initialization a list of existing input devices is
      retrieved from udev. This can lead to a situation where libinput can
      end up processing un-configured devices because of the race generated
      by udev events and libinput startup.
      Sequence example:
      weston - start
      udev - device 1 added
      weston - get a list of input devices
      weston - process device 1 -- undefined behavior
      udev - device 1 added - finalized
      
      The problem was found because of incorrect touchscreen association
      when in a dual monitor system the secondary touchscreen was
      incorrectly associated with output one since udev didn't finish the
      device initialization and WL_OUTPUT was missing.
      
      To avoid this situation we skip un-configured devices during libinput
      initialization, relying on udev to send events when devices are
      fully configured.
      
      Note: due to the peculiarities of udev_device_get_is_initialized(), the
      input device is still processed if the call fails. If there are no udev
      rules defined for the device, it will never be reported as initialized,
      but this is not a problem, because all input devices handled by libinput
      must have some udev properties set, therefore they always have rules.
      Signed-off-by: default avatarNandor Han <nandor.han@ge.com>
      [Pekka: change log to debug, unref device]
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      23d543b7
  5. 03 Apr, 2018 1 commit
  6. 23 Mar, 2018 11 commits
  7. 21 Mar, 2018 3 commits
  8. 20 Mar, 2018 4 commits
  9. 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>
      a1ba6186
    • 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>
      056a5eb6
    • 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
      effects.
      
      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
          libinput:
          - {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
          libinput:
          - {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>
      6e4c8363
  10. 15 Mar, 2018 1 commit
  11. 14 Mar, 2018 1 commit
  12. 13 Mar, 2018 3 commits
  13. 12 Mar, 2018 1 commit
  14. 09 Mar, 2018 3 commits