1. 07 Sep, 2016 1 commit
    • Peter Hutterer's avatar
      tablet: add touch arbitration · b519ea4a
      Peter Hutterer authored
      So far we've relied on the wacom kernel module to do touch arbitration for us
      but that won't be the case in upcoming kernels. Implement touch arbitration in
      userspace by pairing the two devices and suspending the touch device whenever
      a tool comes into proximity.
      
      In the future more sophisticated arbitration can be done (e.g. only touches
      which are close to the pen) but let's burn that bridge when we have to cross
      it.
      
      Note that touch arbitration is "device suspend light", i.e. we leave the
      device enabled and the fd is active. Tablet interactions are comparatively
      short-lived, so closing the fd and asking logind for a new one every time the
      pen changes proximity is suboptimal. Instead, we just keep a boolean around
      and discard all events while it is set.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
      b519ea4a
  2. 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
  3. 09 May, 2016 1 commit
  4. 17 Apr, 2016 2 commits
  5. 08 Apr, 2016 1 commit
  6. 11 Feb, 2016 1 commit
  7. 09 Feb, 2016 1 commit
  8. 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
  9. 11 Jan, 2016 2 commits
    • Peter Hutterer's avatar
      tablet: a tip event can replace an axis event · 1a99977c
      Peter Hutterer authored
      When we're only dealing with BTN_TOUCH we can make the tip event independent
      of the axis event. Now that we handle pressure thresholds to trigger tip state
      this does not work, we'd have to send an axis event with the new pressure and
      then a tip event. Since the pressure triggers the tip event this seems
      disconnected.
      
      Make the tip event officially capable of carrying axes. A caller can then
      decide how to forward this to the next layer.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Acked-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
      1a99977c
    • Peter Hutterer's avatar
      tablet: add pressure threshold handling · 96fbf848
      Peter Hutterer authored
      On tablets with ABS_PRESSURE use a pressure value to determine tip state, not
      BTN_TOUCH. This enables us (down the road) to have device-specific pressure
      thresholds. For now we use a 5% default for all devices.
      
      The threshold is a range, if we go past the upper range we initiate the tip
      down, if we go below the lower range we release the tip again.
      
      This affects two current tests:
      * Once we have pressure offsets and pressure thresholds, we're biased towards
      pressure. So we can only check that distance is zero when there is a pressure
      value, not the other way round.
      * When the pressure threshold is exceeded on proximity in with a nonzero
      distance, we can only warn and handle the pressure as normal. Since this is a
      niche case anyway anything fancier is likely unnecessary.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Acked-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
      96fbf848
  10. 05 Jan, 2016 2 commits
  11. 22 Dec, 2015 1 commit
  12. 14 Dec, 2015 2 commits
  13. 18 Nov, 2015 2 commits
  14. 05 Mar, 2015 1 commit