1. 21 May, 2018 1 commit
    • Peter Hutterer's avatar
      Revert "Expose a custom acceleration profile" · 33162632
      Peter Hutterer authored
      This looked good on paper but clearly no-one (including myself) ever tested this
      in a real-life situation or they would've noticed that the constant factor is
      missing, causing a segfault on the first two-finger scroll event, touchpad
      gesture or button scrolling.
      
      Adding the constant factor makes the API much worse and the benefit is
      unclear, so out of the window it goes. We can revisit this for libinput 1.12
      but this isn't going to make the next release.
      
      This reverts commit d8bd6505.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      33162632
  2. 30 Apr, 2018 1 commit
  3. 26 Apr, 2018 1 commit
    • Peter Hutterer's avatar
      Expose a custom acceleration profile · d8bd6505
      Peter Hutterer authored
      This adds a third profile to the available profiles to map device-specific
      speed to an acceleration factor, fully defined by the caller.
      
      There has been a consistent call for different acceleration profiles in
      libinput, but very little specifics in what actually needs to be changed.
      "faster horses" and whatnot (some notable exceptions in e.g. bug 101139).
      Attempts to change the actual acceleration function will likely break things
      for others.
      
      This approach opens up the profile itself to a user-specific acceleration
      curve. A caller can set an acceleration curve by defining a number of points
      on that curve to map input speed to an output factor. That factor is applied
      to the input delta.
      
      libinput does relatively little besides mapping the deltas to the
      device-specific speed, querying the curve for that speed and applying that
      factor. The curve is device-specific, the input speed is in device units/ms.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      d8bd6505
  4. 05 Sep, 2017 1 commit
  5. 23 Feb, 2017 1 commit
  6. 26 Jan, 2017 1 commit
  7. 14 Aug, 2016 1 commit
  8. 22 Jun, 2016 1 commit
    • Peter Hutterer's avatar
      pad: Add a new API for modes and mode groups · 6583f4bb
      Peter Hutterer authored
      Move mode control to libinput. This reduces some flexibility on what we can do
      with modes but makes it a lot easier for anyone to implement modes correctly
      and have the LEDs apply appropriately, etc. Let's go with the option to make
      the 95% use-case easy. Note: whether the mode is actually used is up to the
      caller, e.g.  under Windows and OS X the mode only applies to the
      rings/strips, not the buttons.
      
      A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned
      to a mode group. That group has a numeric mode index and is hooked to the
      LEDs. libinput will switch the LEDs accordingly.
      
      The mode group is a separate object. This allows for better APIs when it comes
      to:
      * checking whether a button/ring/strip is part of a mode group
      * checking whether a button will trigger a mode transition
      
      and in the future potentially:
      * checking which mode transition will happen
      * setting which button should change the mode transition
      * changing what type of mode transition should happen.
      * moving a button from one mode group to the other
      
      This patch adds the basic scaffolding, without any real implementation.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Proofread-by: default avatarYong Bakos <ybakos@humanoriented.com>
      Reviewed-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      6583f4bb
  9. 15 May, 2016 1 commit
  10. 18 Apr, 2016 1 commit
  11. 17 Apr, 2016 1 commit
    • Peter Hutterer's avatar
      Add the LIBINPUT_DEVICE_CAP_TABLET_PAD capability and matching interface · b2a37069
      Peter Hutterer authored
      This interface handles the buttons on the physical tablet itself, including
      the touch ring and the strip.
      
      A notable difference to other libinput interfaces here is that we do not use
      linux/input.h event codes for buttons. Instead, the buttons are merely
      numbered sequentially, starting at button 1. This means:
      * the API is different, instead of get_button() we have get_button_number() to
        drive the point home
      * there is no seat button count. pads are inherently different devices and
        compositors should treat them as such. The seat button count makes sense
        when you want to know how many devices have BTN_LEFT down, but it makes no
        sense for buttons where all the semantics are handled by the compositor
        anyway.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      b2a37069
  12. 27 Jan, 2016 2 commits
    • Peter Hutterer's avatar
      62a0097d
    • Peter Hutterer's avatar
      touchpad: add a config option to disable tap-and-drag · cba2278c
      Peter Hutterer authored
      There are a number of use-cases where tapping may be desirable, but
      tap-and-drag is not, e.g. where tapping is used to select multiple items in a
      list. Having tap-and-drag on hinders this, and the nature of the interaction
      means it cannot be detected based on timeouts, movement thresholds, etc.
      
      Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
      enabled by default (though tapping is disabled by default).
      
      For the touchpad tap state diagram, the new option disables the transition
      from state TOUCH to state TAPPED and releases the button immediately instead.
      This means that multitap-and-drag is disabled too since we now just loop
      around in the single-tap state for multitap.
      
      It also makes tapping more responsive - we don't have to wait for the timeout
      before we know whether it's a tap event. The first touch time is noted, we now
      send the button press with the time of the first touch and the release with
      the time of the release. This ensures a realistic time diff between the two
      events.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=93502Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.netto>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      cba2278c
  13. 22 Jan, 2016 1 commit
    • Peter Hutterer's avatar
      tablet: add support for relative x/y motion deltas · 108a191a
      Peter Hutterer authored
      Instead of an explicit tablet mode that device must be changed into, let the
      caller decide which coordinates are preferred. The tablet mode may be
      application-specific and usually depends on the tool as well.
      
      This patch adds an interface to get a motion delta for the x/y axes in
      pixel-like coordinates. libinput provides some magic to convert the tablet
      data into something that resembles pixels from a mouse motion.
      For unaccelerated relative motion, the caller should use the mm values from
      the tablet and calculate deltas manually.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Acked-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
      108a191a
  14. 22 Dec, 2015 1 commit
  15. 20 Dec, 2015 4 commits
  16. 18 Nov, 2015 2 commits
  17. 11 Nov, 2015 1 commit
  18. 10 Sep, 2015 1 commit
    • Peter Hutterer's avatar
      Add an API to change pointer acceleration profiles · 8d9e7a1b
      Peter Hutterer authored
      The quartett of new config functions is:
      	libinput_device_config_accel_get_profiles
      	libinput_device_config_accel_get_profile
      	libinput_device_config_accel_set_profile
      	libinput_device_config_accel_get_default_profile
      
      The profile defines how the pointer acceleration works, from a very high-level
      perspective. Two profiles are on offer, "adaptive", the standard one we have
      used so far and "flat" which is a simple multiplier of input deltas and
      provides 1:1 mapping of device movement vs pointer movement.
      
      The speed setting is on top of the profile, a speed of 0 (default) is the
      equivalent to "no pointer acceleration". This is popular among gamers and
      users of switchable-dpi mice.
      
      The flat profile unnormalizes the deltas, i.e. you get what the device does
      and any device below 800dpi will feel excruciatingly slow. The speed range
      [-1, 1] maps into 0-200% of the speed. At 200%, a delta of 1 is translated
      into a 2 pixel movement, anything higher makes it rather pointless.
      
      The flat profile is currently available for all pointer devices but touchpads.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=89485Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      8d9e7a1b
  19. 04 Aug, 2015 1 commit
  20. 28 Jul, 2015 1 commit
  21. 23 Jul, 2015 1 commit
  22. 06 Jul, 2015 5 commits
  23. 23 Jun, 2015 1 commit
    • Peter Hutterer's avatar
      Add configuration interface for tap drag-lock · 75581d58
      Peter Hutterer authored
      In some applications, notably Inkscape, where it is common to frequently drag
      objects a short distance the default to drag-lock always-on is frustrating for
      users.
      Make it configurable, with the current default to "on".
      New API:
        libinput_device_config_tap_set_drag_lock_enabled
        libinput_device_config_tap_get_drag_lock_enabled
        libinput_device_config_tap_get_default_drag_lock_enabled
      
      Any device capable of tapping is capable of drag lock, there is no explicit
      availability check for drag lock. Configuration is independent, drag lock may
      be enabled when tapping is disabled.
      
      In the tests, enable/disable drag-lock explicitly where the tests depend
      on it.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=90928Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      75581d58
  24. 27 May, 2015 1 commit
  25. 23 Apr, 2015 1 commit
  26. 21 Apr, 2015 1 commit
  27. 17 Apr, 2015 1 commit
    • Peter Hutterer's avatar
      Add middle mouse button emulation config options · a6c41156
      Peter Hutterer authored
      Adds the following quartett of functions to enable/disable middle mouse button
      emulation on a device:
      	libinput_device_config_middle_emulation_is_available()
      	libinput_device_config_middle_emulation_set_enabled()
      	libinput_device_config_middle_emulation_get_enabled()
      	libinput_device_config_middle_emulation_get_default_enabled()
      
      This patch only adds the config framework, it is not hooked up to anything
      yet.
      
      Note: like other features this is merely the config option, some devices will
      provide middle button emulation without exposing it as configuration. i.e. the
      return value of libinput_device_config_middle_emulation_is_available() only
      tells you whether you can _configure_ middle button emulation.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      a6c41156
  28. 09 Mar, 2015 1 commit
  29. 06 Mar, 2015 1 commit
    • Peter Hutterer's avatar
      Drop libinput_device_has_button · 595beb93
      Peter Hutterer authored
      And merge all current API versions into the same block. This isn't technically
      necessary since removing libinput_has_button from the code will remove it from
      the exported list. That trips up test/symbols-leak-test though.
      
      Since we break the API and bump the soname in this release anyway, move
      to a single block so the initial stable API is all nicely grouped together.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      595beb93
  30. 02 Mar, 2015 2 commits