1. 03 Jan, 2017 3 commits
  2. 20 Dec, 2016 1 commit
  3. 05 Dec, 2016 1 commit
  4. 19 Nov, 2016 1 commit
    • Peter Hutterer's avatar
      If the parent libinput_device is unavailable, create a new one · 72bac84d
      Peter Hutterer authored
      The parent device ref's the libinput device during pre_init and unref's it
      during DEVICE_INIT, so the copy is lost. During DEVICE_ON, the libinput device
      is re-added and ref'd, this one stays around now. But the takeaway is: unless
      the device is enabled, no libinput device reference is available.
      If a device is a mixed pointer + keyboard device, a subdevice is created
      during a WorkProc. The subdevice relied on the parent's libinput_device being
      available and didn't even check for it. This WorkProc usually runs after
      the parent's DEVICE_ON, so in most cases all is well.
      But when running without logind and the server is vt-switched away, the parent
      device only runs PreInit and DEVICE_INIT but never DEVICE_ON, causing the
      subdevice to burn, crash, and generally fail horribly when it dereferences the
      parent's libinput device.
      Fix this because we have global warming already and don't need to burn more
      things and also because it's considered bad user experience to have the
      server crash. The simple fix is to check the parent device first and if it is
      unavailable, create a new one because it will end up disabled as well anyway,
      so the ref goes away as well. The use-case where the parent somehow gets
      disabled but the subdevice doesn't is a bit too niche to worry about.
      This doesn't happen with logind because in that case we don't get a usable fd
      while VT-switched away, so we can't even run PreInit and never get this far
      (see the paused fd handling in the xfree86 code for that). It can be
      reproduced by setting AutoEnableDevices off, but why would you do that,
      https://bugs.freedesktop.org/show_bug.cgi?id=97117Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
  5. 14 Nov, 2016 1 commit
  6. 01 Nov, 2016 1 commit
  7. 27 Oct, 2016 1 commit
  8. 20 Oct, 2016 1 commit
  9. 19 Oct, 2016 4 commits
  10. 18 Oct, 2016 1 commit
  11. 14 Oct, 2016 1 commit
  12. 18 Sep, 2016 1 commit
  13. 09 Sep, 2016 1 commit
    • Peter Hutterer's avatar
      Always delay hotplugging subdevices · fa69bb1b
      Peter Hutterer authored
      Avoid creating new devices from within the input thread which was the case for
      tablet tools. It requires a lot more care about locking and has a potential to
      mess up things.
      Instead, schedule a WorkProc and buffer all events until we have the device
      created. Once that's done, replay the event sequence so far. If the device
      comes into proximity and out again before we manage to create the new device
      we just ditch the whole sequence and wait for the next proximity in.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  14. 07 Sep, 2016 1 commit
  15. 31 Aug, 2016 1 commit
  16. 19 Aug, 2016 1 commit
  17. 15 Aug, 2016 2 commits
  18. 12 Aug, 2016 2 commits
  19. 08 Jul, 2016 1 commit
  20. 14 Jun, 2016 1 commit
  21. 30 May, 2016 2 commits
  22. 23 May, 2016 1 commit
    • Peter Hutterer's avatar
      Fix proximity events · d8aef838
      Peter Hutterer authored
      Two bugs caused proximity events to be discarded. First, on proximity out
      posting through pDev would be discarded because pDev is the parent device that
      we use as a base for hotplugging the real devices for each tool from. That
      device never sends events though, doing so will see the event discarded in the
      Second, if the tool already exists don't just exit, send the proximity event
      first. To unify the three paths where we do send the events simply move them
      down to the exit phase of the function.
      https://bugs.freedesktop.org/show_bug.cgi?id=95484Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  23. 09 May, 2016 1 commit
    • Peter Hutterer's avatar
      Add tablet pad support · 34b6ed98
      Peter Hutterer authored
      Modelled to be mostly compatible to the xf86-input-wacom driver behavior. The
      pad gets 7 axes, the first three of which are mute and the others are always
      available but obviously only send events when the axis is there.
      The strip axes are incompatible, the wacom driver merely forwards the device
      events (which are a bitshifted value), libinput normalizes it and we just
      expand this back into an integer range. Let's see how we go with this.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  24. 08 May, 2016 1 commit
  25. 28 Apr, 2016 1 commit
  26. 08 Apr, 2016 1 commit
  27. 29 Feb, 2016 4 commits
    • Peter Hutterer's avatar
      Support art pen rotation · 5e7ee73f
      Peter Hutterer authored
      The art pen is a normal pen, but it does provide a rotation axis.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Support the mouse/lens tool · 4564a92d
      Peter Hutterer authored
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Add support for the airbrush tool axes · 0c2bcd03
      Peter Hutterer authored
      Same axes as the pen, but axis number 6 is the wheel (which really is a
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Add support for tablet tools · b4541e4d
      Peter Hutterer authored
      Use two new internal capabilities, CAP_TABLET and CAP_TABLET_TOOL. If a
      libinput tablet device is added, add an X device without any classes. This
      device will not send events, but once we have pad support in libinput we
      may be able to this the pad device.
      When a tool comes into proximity, create a new X device for that serial number
      and start sending events through it. Since the X device only represents a
      single serial number/type combination, some of the wacom-specific
      configuration options fall away. This only matters in the case of multiple
      tools, in which case a per-tool configuration is preferable anyway, so we
      don't lose anything here.
      Gesture support only applied to the touch parts on the device, we don't
      deal with this here specifically - that event node is handled by libinput as
      touchscreen or touchpad.
      This already works with GIMP and clients that don't rely on any
      wacom-driver-specific properties. Configuration clients like
      gnome-settings-daemon will need to change to handle new properties, to be
      added as we go along.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  28. 28 Jan, 2016 2 commits