1. 29 Jun, 2022 1 commit
  2. 28 Jun, 2022 3 commits
  3. 15 Jun, 2022 1 commit
  4. 14 Jun, 2022 1 commit
  5. 11 Jun, 2022 3 commits
  6. 07 Jun, 2022 5 commits
  7. 29 May, 2022 1 commit
    • satrmb's avatar
      filter-touchpad: normalize for dpi on the touchpad-specific flat profile · 92233df5
      satrmb authored
      
      
      On mice, switching the acceleration profile to flat disables dpi normalization,
      because high or even switchable dpi are generally major features of a
      high-end mouse, and switching to flat acceleration indicates that the user
      wants to reduce the effects of any cursor acceleration to a minimum.
      Therefore we skip normalization there and let the user take full advantage
      of their expensive hardware.
      
      On touchpads, particularly those built into a laptop, users have to deal with
      whatever hardware they have; touchpad dpi is an afterthought at best, or
      a disaster at worst. Switching to the flat profile is more likely to be
      about avoiding the non-linear acceleration curve of the adaptive profile.
      
      Hence the flat profile for touchpads shouldn't copy what the one for mice does,
      but rather use dpi normalization like the adaptive profile. This keeps flat
      acceleration on low-resolution touchpads from dropping to unusably slow speeds.
      Signed-off-by: satrmb's avatarsatrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
      92233df5
  8. 23 May, 2022 4 commits
    • Peter Hutterer's avatar
      tablet: require a minimum pressure before we process pressure events · bfbcf173
      Peter Hutterer authored
      Tools default to 1% lower threshold (tip up) and 5% upper threshold (tip
      down). But our distance vs pressure exclusion would reset the distance
      for *any* pressure value, regardless how low that value was and how high
      distance was in comparison.
      
      A very low pressure value of less than 1% would then result in a
      normalized pressure of 0, so we'd effectively just reset the distance to
      zero and do nothing with the pressure. This can cause distance jumps
      when the tool arbitrarily sends low pressure values while hovering as
      seen in https://github.com/libsdl-org/SDL/pull/5481#issuecomment-1118969064
      
      Commit 61bdc05f
      
       from Dec 2017
        "tablet: set the tip-up pressure threshold to 1%"
      was presumably to address this but no longer (?) works.
      
      Fix this by addressing multiple issues at the same time:
      - anything under that 1% threshold is now considered as zero pressure
        and any distance value is kept as-is. Once pressure reaches 1%,
        distance is always zero.
      - axis normalization is now from 1% to 100% (previously: upper threshold
        to 100%). So a tip down event should always have ~4% pressure and we
        may get tablet motion events with nonzero pressure before the tip down
        event.
        From memory, this was always intended anyway since a tip event should
        require some significant pressure, maybe too high compared to e.g.
        pressure-sensitive painting
      - where a tablet has an offset, add the same 1%/5% thresholds, on top of
        that offset. And keep adjusting those thresholds as we change the
        offset. Assuming that the offset is the absolute minimum a worn-out
        pen can reach, this gives us the same behaviour as a new pen. The
        calculation here uses a simple approach so the actual range is
        slightly larger than 5% but it'll do.
      
        Previously, the lower threshold for an offset pen was the axis minimum
        but that can never be reached. So there was probably an undiscovered
        bug in there.
      
      And fix a bunch of comments that were either wrong, confusing or
      incomplete, e.g. the pressure thresholds were already in device
      coordinates.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      bfbcf173
    • Peter Hutterer's avatar
    • Peter Hutterer's avatar
      test: rename a test function to make it easier to select · 393442fd
      Peter Hutterer authored
      
      
      Because --filter-test does substring matching it's easier to have it
      with a unique name rather than one that is a prefix of another.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      393442fd
    • Peter Hutterer's avatar
      tablet: remove an always-true part of an if condition · 374d32c6
      Peter Hutterer authored
      
      
      A few lines north of here we return early if neither bit is set. If we
      get to this point, at least one bit is set so this part of the condition
      always evaluates to true.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      374d32c6
  9. 18 May, 2022 1 commit
  10. 16 May, 2022 3 commits
  11. 09 May, 2022 3 commits
  12. 06 May, 2022 3 commits
  13. 04 May, 2022 2 commits
  14. 26 Apr, 2022 1 commit
  15. 20 Apr, 2022 1 commit
    • Peter Hutterer's avatar
      evdev: strip the device name of format directives · a423d7d3
      Peter Hutterer authored
      This fixes a format string vulnerabilty.
      
      evdev_log_message() composes a format string consisting of a fixed
      prefix (including the rendered device name) and the passed-in format
      buffer. This format string is then passed with the arguments to the
      actual log handler, which usually and eventually ends up being printf.
      
      If the device name contains a printf-style format directive, these ended
      up in the format string and thus get interpreted correctly, e.g. for a
      device "Foo%sBar" the log message vs printf invocation ends up being:
        evdev_log_message(device, "some message %s", "some argument");
        printf("event9 - Foo%sBar: some message %s", "some argument");
      
      This can enable an attacker to execute malicious code with the
      privileges of the process using libinput.
      
      To exploit this, an attacker needs to be able to create a kernel device
      with a malicious name, e.g. through /dev/uinput or a Bluetooth device.
      
      To fix this, convert any potential format directives in the device name
      by duplicating percentages.
      
      Pre-rendering the device to avoid the issue altogether would be nicer
      but the current log level hooks do not easily allow for this. The device
      name is the only user-controlled part of the format string.
      
      A second potential issue is the sysname of the device which is also
      sanitized.
      
      This issue was found by Albin Eldstål-Ahrens and Benjamin Svensson from
      Assured AB, and independently by Lukas Lamster.
      
      Fixes #752
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      a423d7d3
  16. 07 Apr, 2022 1 commit
  17. 06 Apr, 2022 1 commit
  18. 28 Mar, 2022 4 commits
  19. 09 Mar, 2022 1 commit