1. 18 Sep, 2016 1 commit
  2. 13 Sep, 2016 1 commit
  3. 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>
      fa69bb1b
  4. 07 Sep, 2016 1 commit
  5. 31 Aug, 2016 1 commit
  6. 30 Aug, 2016 1 commit
    • Peter Hutterer's avatar
      conf: drop libinput to below the other drivers · 0f7c5ed0
      Peter Hutterer authored
      This is the continuation of 3f569ec4, dropping libinput below the remaining
      drivers. Wacom and synaptics already sort higher anyway (see wacom commit
      0da5cd54 and synaptics commit 59e5db025). evdev remains the catchall
      basic fallback driver and is overwritten by libinput. The two drivers affected
      by this patch are joystick and vmmouse.
      
      joystick is a niche driver and drives devices libinput doesn't handle anyway
      so there is no need to override. If a user installs it, presumably it is to
      use it.
      
      vmmouse is a niche driver and does not assign itself anymore for newer kernel
      drivers (see vmmouse commit 576e8123 from Oct 2014). So if vmmouse is
      installed it can safely sort higher than libinput.
      
      Note: this is upstream behavior, distributions have to work out the wanted
      behavior themselves by renaming the config snippets accordingly.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      0f7c5ed0
  7. 19 Aug, 2016 1 commit
  8. 15 Aug, 2016 3 commits
  9. 12 Aug, 2016 2 commits
  10. 08 Jul, 2016 1 commit
  11. 03 Jul, 2016 1 commit
  12. 14 Jun, 2016 1 commit
  13. 30 May, 2016 2 commits
  14. 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
      server.
      
      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>
      d8aef838
  15. 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>
      34b6ed98
  16. 08 May, 2016 1 commit
  17. 28 Apr, 2016 3 commits
  18. 08 Apr, 2016 1 commit
  19. 07 Apr, 2016 1 commit
  20. 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>
      5e7ee73f
    • 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>
      4564a92d
    • 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
      slider)
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      0c2bcd03
    • 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>
      b4541e4d
  21. 26 Feb, 2016 1 commit
  22. 28 Jan, 2016 2 commits
  23. 27 Jan, 2016 1 commit
  24. 05 Jan, 2016 2 commits
  25. 23 Dec, 2015 1 commit
  26. 17 Dec, 2015 1 commit
    • Peter Hutterer's avatar
      Drain the fd after opening · ad8483b9
      Peter Hutterer authored
      Make sure we don't send any events that may have been enqueued before we
      initialized ourselves. Specifically, if we're using systemd-logind the fd
      remains open when we disable/enable the device, allowing events to queue up on
      the fd. These events are then replayed once the device is re-opened.
      
      This is not the case when VT-switching, in that case logind closes the fd for
      us.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      ad8483b9
  27. 22 Nov, 2015 1 commit
    • Peter Hutterer's avatar
      Split mixed pointer/keyboard devices into two separate X devices · 1f43f392
      Peter Hutterer authored
      The server struggles with devices that are both, the protocol (especially XI2)
      requires a fairly strict separation of pointer vs keyboard devices. Though the
      server has a couple of hacks to route events correctly, mixed
      devices still experience bugs like [1].
      
      Instead of advertising the device as a single mixed device, split the device
      into two X devices, one with only a pointer/touch component, one with only a
      keyboard component. This ensures that the device is effectively attached to
      both the VCP and the VCK, something the XI2 protocol doesn't really allow.
      
      This patch drops the keyboard capability on a mixed device, duplicates the
      input options and attributes and queues a NewInputDeviceRequest call. The new
      device only has the keyboard capability but is otherwise unchanged. The
      wacom driver has used this approach for years.
      
      The WorkProc is necessary to avoid inconsistent state, the server doesn't
      handle a NewInputDeviceRequest during PreInit well.
      
      The approach:
      During pre-init we create a struct xf86libinput_device with the
      libinput_device and a unique ID. The child device has that ID added to the
      options and will look for the other device during its pre-init. The two
      devices then share the xf86libinput_device struct.
      
      We only have a single epollfd for all devices  and the server calls read_input
      on the first device in the list with the epollfd as pInfo->fd. That shared
      struct is used as the userdata on the libinput_device we get back from the
      event, and each device is in the xorg_list device_list of that shared struct.
      We loop through those to find the ones with the right capabilities and
      post the event through that device.
      
      Since devices can be enabled and disabled independently, the rest of the code
      makes sure that we only ever add the device to libinput when the first shared
      device is enabled, and remove it accordingly.
      
      The server uses pInfo->major/minor to detect if another device is using the
      same path for a logind-controlled fd. If so, it reuses that device's
      pInfo->fd and sets the "fd" option to that value. That pInfo->fd is the
      libinput epollfd though, not the actual device fd.
      
      This doesn't matter for us, since we manage the fds largely ourselves and the
      pInfo->fd we use is the epollfd anyway. On unplug however, the udev code
      triggers a device removal for all devices, including the duplicated ones. When
      we disable device, we restore the pInfo->fd from the "fd" option so that the
      server can request logind to close the fd.
      
      That only works if the "fd" option is correct, otherwise the server asks
      logind to close the epollfd and everyone is unhappy.
      
      [1] https://bugs.freedesktop.org/show_bug.cgi?id=49950
      
      https://bugs.freedesktop.org/show_bug.cgi?id=92896Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      1f43f392
  28. 20 Nov, 2015 1 commit
    • Peter Hutterer's avatar
      Revert "Split mixed pointer/keyboard devices into two separate X devices" · 83dfd31e
      Peter Hutterer authored
      When using logind, this causes the server to hang when a split device is
      unplugged. The reason is mostly in the server, when open the device by
      requesting the logind fd, the server loops through the device list to check if
      any other device has the same major/minor (see systemd_logind_take_fd()) and
      returns the pInfo->fd for that device instead of requesting the fd again from
      logind.
      
      For libinput devices, the pInfo->fd is the epollfd, not the actual device, so
      our second device gets the epollfd assigned. When the devices are removed, we
      keep the device fd open and release the epollfd through logind.
      
      This reverts commit c943739a.
      83dfd31e
  29. 19 Nov, 2015 1 commit
    • Peter Hutterer's avatar
      Split mixed pointer/keyboard devices into two separate X devices · c943739a
      Peter Hutterer authored
      The server struggles with devices that are both, the protocol (especially XI2)
      requires a fairly strict separation of pointer vs keyboard devices. Though the
      server has a couple of hacks to route events correctly, mixed
      devices still experience bugs like [1].
      
      Instead of advertising the device as a single mixed device, split the device
      into two X devices, one with only a pointer/touch component, one with only a
      keyboard component. This ensures that the device is effectively attached to
      both the VCP and the VCK, something the XI2 protocol doesn't really allow.
      
      This patch drops the keyboard capability on a mixed device, duplicates the
      input options and attributes and queues a NewInputDeviceRequest call. The new
      device only has the keyboard capability but is otherwise unchanged. The
      wacom driver has used this approach for years.
      
      The WorkProc is necessary to avoid inconsistent state, the server doesn't
      handle a NewInputDeviceRequest during PreInit well.
      
      The approach:
      During pre-init we create a struct xf86libinput_device with the
      libinput_device and a unique ID. The child device has that ID added to the
      options and will look for the other device during its pre-init. The two
      devices then share the xf86libinput_device struct.
      
      We only have a single epollfd for all devices  and the server calls read_input
      on the first device in the list with the epollfd as pInfo->fd. That shared
      struct is used as the userdata on the libinput_device we get back from the
      event, and each device is in the xorg_list device_list of that shared struct.
      We loop through those to find the ones with the right capabilities and
      post the event through that device.
      
      Since devices can be enabled and disabled independently, the rest of the code
      makes sure that we only ever add the device to libinput when the first shared
      device is enabled, and remove it accordingly.
      
      [1] https://bugs.freedesktop.org/show_bug.cgi?id=49950
      
      https://bugs.freedesktop.org/show_bug.cgi?id=92896Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      c943739a