1. 16 Jan, 2022 1 commit
  2. 29 May, 2018 2 commits
  3. 30 Jan, 2018 1 commit
  4. 16 Jan, 2018 1 commit
  5. 03 Jan, 2017 1 commit
  6. 23 Oct, 2016 1 commit
  7. 01 Jun, 2016 1 commit
  8. 12 May, 2016 1 commit
  9. 26 Apr, 2016 1 commit
  10. 20 Jan, 2016 1 commit
  11. 12 Nov, 2015 1 commit
  12. 27 Aug, 2015 1 commit
  13. 15 Mar, 2015 1 commit
  14. 13 Mar, 2015 1 commit
  15. 11 Mar, 2015 5 commits
  16. 12 Feb, 2015 1 commit
  17. 23 Jan, 2015 1 commit
  18. 23 Dec, 2014 1 commit
  19. 17 Dec, 2014 5 commits
  20. 07 Nov, 2014 1 commit
  21. 29 Sep, 2014 1 commit
  22. 29 Aug, 2014 1 commit
  23. 18 Aug, 2014 3 commits
    • Peter Hutterer's avatar
      If only IgnoreRelativeAxes is set, init like a normal relative device · 977588d2
      Peter Hutterer authored
      
      
      In the current code, if only IgnoreRelativeAxes is set, the code would go on
      and force absolute axes to initialize even if the relative axes were
      successfully initialized.
      
      Evdev gives precedence to relative axes anyway, initializing absolute axes if
      the relative axes failed. Thus, if we explicitely want relative axes but leave
      the abs axes as-is, proceed as normal.
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      977588d2
    • Peter Hutterer's avatar
      Fix axis initialization for devices with abs x/y and rel scrollwheels · 291b6017
      Peter Hutterer authored
      
      
      The Xen Virtual Pointer device has ABS_X, ABS_Y and REL_WHEEL. If smooth
      scrolling is detected, the current code would first initialize relative axes
      for scrolling and immediately overwrite those axes when the abs valuators are
      written out.
      
      This patch fixes the default case only, in the case of a device setting the
      two Ignore*Axis options both to "off", the axes are still overwritten. The
      wheels will work, other axes only if the same number of abs axes exists. And
      it keeps the current memory leak too, but it's marked with a FIXME now.
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      291b6017
    • Peter Hutterer's avatar
      Make the slot-state per slot · 8ce06c96
      Peter Hutterer authored
      
      
      The previous approach only had the slot state for the current slot. If we
      changed slots, that means we lost the information if the slot was ever
      initialized. If the ABS_MT_TRACKING_ID was never received, the slot would
      still update and try to send events (which the server refused with a warning).
      
      Avoid this by having a per-slot state and a dirty bit that tells us if the
      current slot updated at all. If we don't get the tracking ID, leave the slot
      empty and refuse any further events from that touch.
      
      This quashes the various "unable to find touch point 0" warnings caused if a
      touchpoint starts before the device is enabled.
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Walter Harms's avatarWalter Harms <wharms@bfs.de>
      8ce06c96
  24. 06 May, 2014 1 commit
  25. 28 Apr, 2014 3 commits
  26. 10 Mar, 2014 1 commit
  27. 22 Oct, 2013 1 commit