1. 12 Feb, 2019 1 commit
    • Peter Hutterer's avatar
      Upgrade the default scroll distance to 120 · 05548118
      Peter Hutterer authored
      This is just a number, to be used as divider and shouldn't have any effect in
      correctly written clients. With the high-res scrolling coming up however, we
      have a few devices where the dist cannot be expressed as an integer fraction
      of 15, so let's up it to 120 because we know all hardware wheels have to be an
      integer fraction of that that, thanks to Microsoft's API requirements.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      05548118
  2. 04 Feb, 2019 1 commit
  3. 25 Jan, 2019 1 commit
    • Peter Hutterer's avatar
      Handle scroll wheel events with a discrete of 0 · e7eafa19
      Peter Hutterer authored
      The driver currently assumes that any wheel event has a non-zero discrete
      value of 1. This is incorrect, it just hasn't triggered yet with any device.
      
      With the hi-res scroll patches in place in the kernel and libinput, we may get
      wheel events with a discrete value of 0. We assume that if this ever happens,
      the device has some sensible click angle set so all we need to do is ignore
      the discrete 0 events and wait for the first discrete event to come.
      
      Also add an explanatory comment too to make it clear the calculation is only
      done once.
      
      Fixes #19Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      e7eafa19
  4. 23 Jan, 2019 1 commit
  5. 21 Jan, 2019 1 commit
  6. 07 Jan, 2019 1 commit
  7. 25 Nov, 2018 1 commit
  8. 18 Nov, 2018 1 commit
  9. 15 Oct, 2018 1 commit
  10. 14 Oct, 2018 1 commit
  11. 04 Oct, 2018 1 commit
  12. 19 Jul, 2018 1 commit
  13. 11 Jul, 2018 2 commits
  14. 10 Jul, 2018 1 commit
  15. 22 May, 2018 1 commit
  16. 02 May, 2018 1 commit
  17. 20 Apr, 2018 2 commits
  18. 17 Apr, 2018 2 commits
  19. 09 Apr, 2018 1 commit
  20. 22 Mar, 2018 1 commit
  21. 20 Mar, 2018 2 commits
  22. 20 Feb, 2018 1 commit
    • Peter Hutterer's avatar
      Apply the capabilities checks on subdevices when applying the config · 9d9f59fd
      Peter Hutterer authored
      Properties are initialized on the correct devices only but on resume we'd just
      blindly apply the config from our device. Depending on the resume order, this
      would mean we'd apply a previously set config with a default config.
      
      Example:
      * pointer device with keyboard subdevice
      * pointer device exports natural scrolling, keyboard device does not and
        remains at default (off)
      * client enables natural scrolling on the pointer device
      * VT switch away, VT switch back
      * pointer device gets enabled first, enables natural scrolling on the
        libinput device
      * keyboard device gets enabled second, resets to the default value
      Reported-by: yshui's avatarYuxuan Shui <yshuiv7@gmail.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Tested-by: yshui's avatarYuxuan Shui <yshuiv7@gmail.com>
      9d9f59fd
  23. 02 Feb, 2018 2 commits
  24. 15 Sep, 2017 1 commit
  25. 17 Aug, 2017 1 commit
  26. 28 May, 2017 1 commit
  27. 18 May, 2017 1 commit
  28. 15 May, 2017 1 commit
  29. 08 May, 2017 1 commit
  30. 05 May, 2017 1 commit
  31. 22 Mar, 2017 1 commit
    • Peter Hutterer's avatar
      Post a motion event after proximity events · 8bc69459
      Peter Hutterer authored
      This patch splits the meat of xf86libinput_handle_tablet_axis into a helper
      function xf86libinput_post_tablet_motion(), to be called right after we send
      the proximity in event.
      
      Clients that don't handle proximity (e.g. all XI2 clients) don't see the
      coordinates we send along with the proximity events. And, for historical
      reasons, they may not look at the coordinates in button events. So a device
      that comes into proximity and immediately sends a tip down button event
      doesn't send a motion event, causing the client to think the tip down was at
      whatever the last known position was (before previous prox-out).
      
      The practical effect is that when a user tries to draw a few dots, they end up
      being connected to each other.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1433755Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      8bc69459
  32. 09 Mar, 2017 1 commit
  33. 28 Feb, 2017 1 commit
    • Peter Hutterer's avatar
      test: fix a test failure on ppc64(le) and aarch64 · 72fb6d30
      Peter Hutterer authored
      Caused by different results in -O0 vs -O2. The resulting array differs only
      slightly but the initial sequence has one extra zero. That triggers our
      assert, no other compiler flag seem to be affecting this.
      
      Compiled with -O0:
      Breakpoint 1, test_nonzero_x_linear () at test-bezier.c:157
      157			assert(bezier[x] > bezier[x-1]);
      (gdb) p bezier
      $6 = {0 <repeats 409 times>, 1, 2, 4, 5, 7, 9, 10, 12, 14, 15, 17, 19, 21, 22,
      
      Compiled with -O2:
      (gdb) p bezier
      $1 = {0 <repeats 410 times>, 1, 3, 5, 7, 9, 10, 12, 14, 15, 17, 19, 20, 22,
      
      Printing of the temporary numbers in the decasteljau function shows that a few
      of them are off by one, e.g.
          408.530612/0.836735 with O0, but
          409.510204/0.836735 with O2
      Note: these are not rounding errors caused by the code, the cast to int
      happens afterwards.
      
      Hack around this by allowing for one extra zero before we check that the rest
      of the curve is ascending again.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=99992Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      72fb6d30
  34. 26 Feb, 2017 2 commits