1. 14 Oct, 2018 1 commit
  2. 04 Oct, 2018 1 commit
  3. 19 Jul, 2018 1 commit
  4. 11 Jul, 2018 2 commits
  5. 10 Jul, 2018 1 commit
  6. 22 May, 2018 1 commit
  7. 02 May, 2018 1 commit
  8. 20 Apr, 2018 2 commits
  9. 17 Apr, 2018 2 commits
  10. 09 Apr, 2018 1 commit
  11. 22 Mar, 2018 1 commit
  12. 20 Mar, 2018 2 commits
  13. 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.
      * 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>
  14. 02 Feb, 2018 2 commits
  15. 15 Sep, 2017 1 commit
  16. 17 Aug, 2017 1 commit
  17. 28 May, 2017 1 commit
  18. 18 May, 2017 1 commit
  19. 15 May, 2017 1 commit
  20. 08 May, 2017 1 commit
  21. 05 May, 2017 1 commit
  22. 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>
  23. 09 Mar, 2017 1 commit
  24. 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>
  25. 26 Feb, 2017 3 commits
  26. 09 Feb, 2017 1 commit
  27. 27 Jan, 2017 1 commit
  28. 26 Jan, 2017 2 commits
  29. 12 Jan, 2017 1 commit
    • Peter Hutterer's avatar
      Add tablet tool area ratio property · 974ab6b6
      Peter Hutterer authored
      By default, the X server maps the tablet axes to the available screen area.
      When a tablet is mapped to the screen but has a different aspect ratio than
      the screen, input data is skewed. Expose an area ratio property to map the
      a subsection of the available tablet area into the desired ratio.
      Differences to the wacom driver: there the x/y min/max values must be
      specified manually and in device coordinates. For this driver we merely
      provide the area ratio (e.g. 4:3) and let the driver work out the rest.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
  30. 03 Jan, 2017 3 commits
    • Peter Hutterer's avatar
      Implement stylus pressure curve support · 5d047073
      Peter Hutterer authored
      Takes a 4-point cubic bezier curve as input and maps the pressure coordinates
      to the values outlined by this curve. This is an extension of the current
      implementation in the xf86-input-wacom driver which only allows the two center
      control points to be modified.
      Over the years a few users have noted that the wacom driver's pressure curve
      makes it impossible to cap the pressure at a given value. Given our bezier
      implementation here, it's effectively a freebie to add configurability of the
      first and last control points. We do require all control points' x coordinates
      to be in ascending order.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Add a bezier curve implementation · f65a5c50
      Peter Hutterer authored
      Needed for the wacom stylus pressure curve
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Calculate the required scroll distance based on the angle · 0dad7408
      Peter Hutterer authored
      For a mouse with a click angle of 15 degrees things are unchanged. For devices
      with angles less than 10, the current code scrolled way too fast. Because the
      angle wasn't used anywhere, each tick would count as full scroll wheel event,
      a slight movement of the wheel would thus scroll as much as a large movement
      on a normal mouse.
      Fix this by taking the actual click angle of the device into account. We
      calculate some multiple of the angle that's close enough to the default 15
      degrees of the wheel and then require that many click events to hit the full
      scroll distance. For example, a mouse with a click angle of 3 degrees now
      requires 5 clicks to trigger a full legacy scroll button event.
      XI2.1 clients get the intermediate events (i.e. in this case five times
      one-fifth of the scroll distance) and can thus scroll smoothly, or more
      specifically in smaller events than usual.
      https://bugs.freedesktop.org/show_bug.cgi?id=92772Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>