1. 17 Sep, 2022 1 commit
    • neldredge's avatar
      Recognize "stylus" devices as GDK_SOURCE_PEN · 8984b13d
      neldredge authored and Luca Bacci's avatar Luca Bacci committed
      Add "stylus" to the list of substrings in a device name that cause it to be recognized
      as a GDK_SOURCE_PEN device (previously "wacom", "pen" and "eraser").  Some devices
      just use "stylus" in their name, and are otherwise recognized as
      GDK_SOURCE_TOUCHSCREEN instead.
      
      Fixes #4394.
      8984b13d
  2. 02 Dec, 2021 1 commit
  3. 27 Jan, 2020 1 commit
  4. 18 Dec, 2018 3 commits
    • Peter Hutterer's avatar
      x11: make the tool lookup dependent on the hw id as well · 7b33369b
      Peter Hutterer authored
      Tools on the same physical item have the same serial number, so the eraser
      and the pen part of a single pen share that serial number. With the current
      lookup code, we'll always return whichever tool comes first into proximity.
      
      Change the code to use the hw id in addition to the serial number, this way we
      can differ between two tools.
      7b33369b
    • Peter Hutterer's avatar
      x11: don't add unknown tools to our list · c6dd9229
      Peter Hutterer authored
      Generic tools (Bamboo, built-in tablets) always have the same serial number
      assigned by the wacom driver. This includes the touch tool when the wacom
      driver handles the touch evdev node (common where users require the wacom
      gestures to work).
      
      When the first device is the touch device, a tool is created with that serial.
      All future tools now return the touch tool on lookup since they all share the
      same serial number. Worse, this happens *across* devices, so the pen
      event node gets assigned the touch tool because they all have the same serial.
      
      Since we don't actually care about the touch as a tool, let's skip any unknown
      tool. This captures pads as well.
      c6dd9229
    • Peter Hutterer's avatar
      x11: get the tool type from the wacom driver properties · f173d1bc
      Peter Hutterer authored
      Any wacom device currently sets the tool type to UNKNOWN. The wacom driver has
      a property that exports the tool type as one of stylus, eraser, cursor, pad or
      touch. Only three of those are useful here but that's better than having all
      of them as unknown.
      f173d1bc
  5. 20 Jun, 2018 1 commit
  6. 17 Aug, 2017 1 commit
  7. 30 Jun, 2017 1 commit
  8. 20 Mar, 2017 1 commit
  9. 29 Aug, 2016 1 commit
    • Matthias Clasen's avatar
      x11: Fix a trap mixup · c9749ad7
      Matthias Clasen authored
      There was a return between a push/pop of an error trap, and
      this managed to trigger the 'unpopped trap' warning in the
      displayclose test now. Fix this.
      c9749ad7
  10. 23 Aug, 2016 1 commit
  11. 01 Jun, 2016 1 commit
  12. 10 May, 2016 1 commit
  13. 22 Apr, 2016 1 commit
  14. 09 Apr, 2016 1 commit
  15. 06 Apr, 2016 5 commits
  16. 08 Mar, 2016 1 commit
  17. 26 Feb, 2016 1 commit
  18. 25 Feb, 2016 2 commits
  19. 18 Jan, 2016 1 commit
  20. 13 Jan, 2016 1 commit
  21. 14 Dec, 2015 2 commits
  22. 17 Nov, 2015 1 commit
  23. 15 Nov, 2015 1 commit
  24. 03 Nov, 2015 1 commit
  25. 09 Sep, 2015 1 commit
  26. 15 Jul, 2015 1 commit
  27. 01 Jul, 2015 1 commit
    • Carlos Garnacho's avatar
      x11: Query pointer devices' scroll valuators on toplevel enter events · 77b8495b
      Carlos Garnacho authored
      We used to "invalidate" scroll valuators, so the next scroll event could
      be used as the base for the next scroll deltas. This has the inconvenience
      that it invariably consumes the first event received after enter and,
      due to interactions with WM overeager passive button grabs, there's a
      possibility we don't scroll at all if we receive interleaved "smooth
      scroll" XI_Motion events and XI_Enter events (Normally triggered by regular
      scroll wheels in mice).
      
      In order to fix this, and at the expense of some sync-call overhead on
      XI_Enter events (one XIQueryDevice call per slave device), query the
      current scroll valuator state for all the slaves of the entered pointer,
      so we do know beforehand the right base values. If new devices are plugged
      while the pointer is on top of the client, the initialized scroll values
      will match the valuators'.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=750994
      https://bugzilla.gnome.org/show_bug.cgi?id=750870
      77b8495b
  28. 02 Jun, 2015 1 commit
  29. 02 Mar, 2015 1 commit
  30. 02 Feb, 2015 1 commit
    • Carlos Garnacho's avatar
      x11: Detect libinput touchpads · 6f07d5e7
      Carlos Garnacho authored
      These aren't reported as XIDependentTouch devices, so make it poke a
      property that's specific to touchpads managed by the libinput driver.
      6f07d5e7
  31. 19 Jan, 2015 1 commit
  32. 29 Jun, 2014 1 commit