1. 21 Sep, 2017 1 commit
    • Peter Hutterer's avatar
      test: switch to a TEST_DEVICE macro for all the litest test devices · 2346801b
      Peter Hutterer authored
      The test device initialization code was a bit of duplicated boilerplate and
      required adding a reference to the devices to the 'devices' list in litest.c.
      Automate this with a new TEST_DEVICE macro that adds the devices to a custom
      section in the binary, then loops throught that section to get the device out.
      
      This reduces the boilerplate for each test device to just the TEST_MACRO and
      the LITEST_foo device enum entry. It also now automates the shortname of the
      device.
      
      The device's shortname was standardised in this approach as well, lowercase
      and dashes only.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      2346801b
  2. 12 Jan, 2017 1 commit
  3. 01 Dec, 2016 1 commit
  4. 09 Sep, 2016 1 commit
  5. 12 Jul, 2015 1 commit
  6. 09 Jul, 2015 1 commit
  7. 16 Jun, 2015 1 commit
  8. 23 Jul, 2014 1 commit
    • Peter Hutterer's avatar
      test: auto-update for BTN_TOOL_* when using litest_touch_ functions · 61995348
      Peter Hutterer authored
      Set BTN_TOUCH, BTN_TOOL_DOUBLETAP automatically depending on the number of
      fingers down.
      
      This emulates real event sequences a bit better than the current approach,
      though it's not a 100% correct emulation:
      1) On real devices, BTN_* are usually sent last before the SYN_REPORT - here
         they are sent first to slot in with the custom, device-specific event
         sequence. We should only ever look at the complete sequence anyway, so this
         shouldn't matter.
      2) On real devices, the switch from BTN_TOOL_DOUBLETAP to TRIPLETAP and vice
         versa is not always toggled within the same SYN_REPORT
      3) On synaptics devices, BTN_TOUCH is released in the frame where
         BTN_TOOL_DOUBLETAP is set. It is then immediately set again in the next
         frame.  With the current litest framework this is hard to integrate, so we
         just leave BTN_TOUCH set the whole time, which is what MT devices do if
         they don't have BTN_TOOL_DOUBLETAP.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      61995348
  9. 10 Jun, 2014 2 commits
  10. 03 Jun, 2014 1 commit
  11. 10 Apr, 2014 1 commit
  12. 08 Apr, 2014 3 commits
  13. 24 Mar, 2014 1 commit
  14. 15 Jan, 2014 1 commit
    • Peter Hutterer's avatar
      Add a device test suite · 3a344169
      Peter Hutterer authored
      A rather large commit, copied from a similar (almost identical) suite in
      libtouchpad and ported for libinput.
      
      The goal here is to make testing for various devices easy, so the litest
      ("libinput test") wrappers do that. The idea is that each device has some
      features, and tests are likely to exercise some features or won't work with
      other features.
      
      Each test case takes a list of required features and a list of excluded
      features. The test suite will create a new test case for each device in the
      suite that matches that set.
      
      For example, the set of required LITEST_TOUCHPAD, excluded LITEST_BUTTON would
      run on clickpads only, not on touchpads with buttons.
      
      check supports suites and test cases, both named. We wrap that so that each
      named set of cases we add are a test suite, with the set of devices being the
      test cases. i.e.
      
      litest_add("foo:bar", some_test_function, LITEST_ANY, LITEST_ANY);
      
      adds a suite named "foo:bar" and test cases for both devices given, with their
      shortnames as test case name, resulting in:
         "foo:bar", "trackpoint"
         "foo:bar", "clickpad"
         ...
      
      Multiple test functions can be added to a suite. For tests without a device
      requirement there is litest_add_no_device_test(...).
      
      The environment variables CK_RUN_SUITE and CK_RUN_CASE can be used to narrow
      the set of test cases. The test suite detects when run inside a debugger and
      disables fork mode (the default).
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      3a344169