1. 04 May, 2017 1 commit
  2. 23 Mar, 2017 1 commit
  3. 14 Mar, 2017 1 commit
  4. 22 Feb, 2017 1 commit
  5. 09 Feb, 2017 1 commit
  6. 01 Feb, 2017 1 commit
  7. 20 Jan, 2017 5 commits
  8. 16 Jan, 2017 1 commit
  9. 15 Jan, 2017 2 commits
  10. 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
      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>
  11. 01 Sep, 2016 2 commits
  12. 02 Aug, 2016 2 commits
  13. 30 May, 2016 1 commit
    • Peter Hutterer's avatar
      tablet: up the reference count for the tool in the event · cf707baa
      Peter Hutterer authored
      Make sure that the tool is valid while the event is valid, even if the device
      gets destroyed before the event is destroyed.
      This cannot actually be triggered right now, the event has a ref to the device
      and the tools do not get removed until the device is destroyed. But for future
      implementations (e.g. where the tool is otherwise automatically destroyed on
      proximity out) we need to ensure the tool remains valid for the event
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  14. 27 Apr, 2016 1 commit
  15. 11 Apr, 2016 1 commit
  16. 10 Apr, 2016 1 commit
    • Jonas Ådahl's avatar
      test: Handle 32 bit msec time overflows · 240d669b
      Jonas Ådahl authored
      The libinput_*_get_time() returns a 32 bit unsigned integer, but in the
      tests we compared them to a 64 bit unsigned integer. This means that
      when the 32 bit integer overflowed, we'd still compare to a
      non-overflowed 64 bit integer, causing the tests to fail.
      This commit fixes this by always casting the millisecond 64 bit unsigned
      integer to a 32 unsigned integer, triggering the same overflow.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  17. 23 Feb, 2016 1 commit
  18. 11 Feb, 2016 2 commits
  19. 10 Feb, 2016 3 commits
  20. 09 Feb, 2016 1 commit
  21. 22 Jan, 2016 2 commits
  22. 11 Jan, 2016 3 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
      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>
    • 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>
    • Peter Hutterer's avatar
      test: fix a bunch of tablet tests for pressure threshold introduction · 8d79b718
      Peter Hutterer authored
      Preparation work for a pressure threshold where we can't just send a BTN_TOUCH
      and expect it to trigger the tip event. So the event sequence now needs to
      resemble the right order so the threshold will be triggered.
      In some cases requires processing an axis event before the tip event. That
      behavior will be changed in a follow-up commit.
      It also requires that all tablets set ABS_PRESSURE on proximity in.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Acked-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
  23. 06 Jan, 2016 1 commit
  24. 23 Dec, 2015 1 commit
  25. 22 Dec, 2015 3 commits