1. 29 Jul, 2019 1 commit
    • Jason Gerecke's avatar
      udev: Reproduce entire LIBINPUT_DEVICE_GROUP for paired ExpressKey Remote · 5521ab03
      Jason Gerecke authored
      In order for two devices to be in the same group, they need to share
      identical LIBINPUT_DEVICE_GROUP attributes. The `wacom_handle_ekr` function
      overwrites the VID/PID for an ExpressKey Remote, but the 'phys' path is
      left unchanged. This only works if the EKR and the device we want to pair
      it with are both direct sibings in the USB tree. It isn't always possible
      to actually connect the devices like this, however. The Cintiq Pro 32 and
      24, for instance, have multiple internal USB hubs and place the pen sensor
      and the USB port for the EKR dongle behind different ones.
      By copying the 'phys' path of the device we want to pair with, it is
      possible to reproduce the entire LIBINPUT_DEVICE_GROUP and ensure that
      the two devices actually end up paired in libinput.
      Signed-off-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
  2. 26 Jun, 2019 3 commits
  3. 07 Jun, 2019 1 commit
  4. 14 Mar, 2019 1 commit
  5. 07 Feb, 2019 1 commit
  6. 10 Sep, 2018 2 commits
  7. 18 Jun, 2018 1 commit
  8. 08 Jun, 2018 1 commit
  9. 05 Jun, 2018 1 commit
  10. 03 Jun, 2018 1 commit
    • Peter Hutterer's avatar
      Revert "udev: copy the trackpoint sensitivity directly from sysfs" · 085a33d5
      Peter Hutterer authored
      The lenovo compact keyboard with trackpoint has a sensitivity of 5, which
      causes the trackpoint range to be 0. This in turn causes inf/NaN during
      pointer acceleration as we divide by 0 and makes the cursor go unpredictably
      somewhere it probably shouldn't be.
      This is part of a wider problem in that the current sensitivity handling
      doesn't work well for values well below the default of 128. Any such values
      are scaled up to multiples of pixels instead of just working as-is.
      Reverting the automatic sensitivity parsing, any systemd udev property set to
      change the sensitivity increases it, so we don't run into this bug.
      This reverts commit a4036a33.
  11. 31 May, 2018 2 commits
  12. 29 May, 2018 3 commits
  13. 24 May, 2018 1 commit
  14. 17 May, 2018 1 commit
  15. 14 May, 2018 1 commit
  16. 09 May, 2018 1 commit
  17. 03 May, 2018 1 commit
    • Peter Hutterer's avatar
      udev: copy the trackpoint sensitivity directly from sysfs · a4036a33
      Peter Hutterer authored
      Rather than going the roundabout way of having systemd set the sensitivity
      followed by us reading that udev property and hoping, just take the
      sensitivity directly from sysfs. This makes us basically independent of what
      systemd does (or the lack of systemd, where that is a problem).
      It does remove the chance of users to trick libinput by manually adjusting the
      sensitivity after the udev rules kicked in, but seriously, we should work on
      fixing acceleration properly in that case.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  18. 01 May, 2018 1 commit
  19. 25 Apr, 2018 1 commit
  20. 20 Apr, 2018 1 commit
  21. 19 Apr, 2018 1 commit
  22. 18 Apr, 2018 2 commits
  23. 17 Apr, 2018 2 commits
  24. 13 Apr, 2018 1 commit
  25. 12 Apr, 2018 1 commit
  26. 09 Apr, 2018 1 commit
  27. 23 Mar, 2018 4 commits
  28. 20 Mar, 2018 1 commit
  29. 08 Mar, 2018 1 commit
    • Peter Hutterer's avatar
      Extract and reset the abs fuzz value for the x/y axes · 1523d8bb
      Peter Hutterer authored
      The kernel fuzz handling is buggy, especially when we want to rely on the fuzz
      value for our hysteresis. But since this is a hw property and (at least
      sometimes) set by the driver, we can't make this a pure libinput hwdb set
      So our workaround is:
      * extract the (non-zero) fuzz into a udev property so we don't lose it
      * set the fuzz to 0 to disable the in-kernel hysteresis
      * overwrite our internal absinfo with the property fuzz
      This way we get to use the hw-specified fuzz without having the kernel muck
      around with it. We also get to use the EVDEV_ABS_ values in 60-evdev.hwdb to
      override a driver-set fuzz.
      Two drawbacks:
      - we're resetting the kernel fuzz to 0, this affects any other users of the
        device node. That's probably a minor impact only.
      - we can only save this in a udev property there's a risk of this information
        getting lost when playing around with udev rules. That too should be a minor
      https://bugs.freedesktop.org/show_bug.cgi?id=105303Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>