Skip to content

GitLab

Switch branch/tag
  1. 29 Jun, 2022 1 commit
  3. 28 Jun, 2022 3 commits
  5. 15 Jun, 2022 1 commit
  7. 14 Jun, 2022 1 commit
  9. 11 Jun, 2022 3 commits
  11. 07 Jun, 2022 5 commits
  13. 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
  15. 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
      tablet: use a helper variable to make the code more readable · 988329d5
      Peter Hutterer authored 
      
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      988329d5
    • 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
  17. 18 May, 2022 1 commit
  19. 16 May, 2022 3 commits
  21. 09 May, 2022 3 commits
  23. 06 May, 2022 3 commits
  25. 04 May, 2022 2 commits
  27. 26 Apr, 2022 1 commit
  29. 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
  31. 07 Apr, 2022 1 commit
  33. 06 Apr, 2022 1 commit
  35. 28 Mar, 2022 4 commits
  37. 09 Mar, 2022 1 commit