Skip to content
  1. May 20, 2020
  3. May 18, 2020
    • Peter Hutterer's avatar
      fallback: always emulate a high-resolution wheel · c8bdf36d
      Peter Hutterer authored 
      

Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      c8bdf36d
    • Peter Hutterer's avatar
      Add LIBINPUT_EVENT_POINTER_AXIS_WHEEL to get normalized wheel scrolling · c76aac58
      Peter Hutterer authored 
      

Starting with kernel v5.0 two new axes are available for high-resolution wheel
scrolling: REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES. Both axes send data in
fractions of 120 where each multiple of 120 amounts to one logical scroll
event. Fractions of 120 indicate a wheel movement less than one detent.

This commit adds a new API for pointer axis events. A new event type and a new
API to get a normalized-to-120 value also used by Windows and the kernel, each
multiple of 120 represents a logical scroll click.

This addresses a main shortcoming with the existing API - it was unreliable to
calculate the click angle based on the axis value+discrete events and thus any
caller using the axis value alone would be left with some ambiguity. With the
v120 API it's now possible to (usually) calculate the click angle, but more
importantly it provides the simplest hw-independent way of scrolling by a
click or a fraction of a click.

A new event type is required, the only way to integrate the v120 value
otherwise was to start sending events with a discrete value of 0. This
would break existing xf86-input-libinput (divide by zero, fixed in 0.28.2) and
weston (general confusion). mutter, kwin are unaffected.

Notable: REL_WHEEL/REL_HWHEEL are emulated by the kernel but there's no
guarantee that they'll come every accumulated 120 values, e.g. Logitech mice
often send events that don't add up to 120 per detent.

We use the kernel's wheel click emulation instead of doing our own.

Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      c76aac58
    • Peter Hutterer's avatar
      Deprecate wheel tilt as separate axis source · fdc83c13
      Peter Hutterer authored 
      

This has never been supported through the stack. No device ever had the
required MOUSE_WHEEL_TILT_VERTICAL/HORIZONTAL udev property set, so
libinput never set the right axis source. Neither weston nor mutter
added the code for it. Even if we added wheel tilt for devices now, it
would break those devices. And the benefit we get from having those
separate is miniscule at best.

So let's do the long-term thing and just deprecate this axis source.

The wheel tilt mouse test device remains in the test suite, with the
udev properties set just to verify that we do indeed ignore those now.

Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      fdc83c13
  5. May 13, 2020
    • Peter Hutterer's avatar
      evdev: warn if our event processing lags by 10ms or more · bd7b9106
      Peter Hutterer authored 
      

Take a snapshot of the time every 10 libinput_dispatch() calls. During event
processing, check if the event timestamp is more than 10ms in the past and
warn if it is. This should provide a warning to users when the compositor is
too slow to processes events but events aren't coming in fast enough to
trigger SYN_DROPPED.

Because we check the device event time against the dispatch time we may get
warnings for multiple devices on delayed processing. This is intended, it's
good to know which devices were affected.

In the test suite we need to ignore the warning though, since we compose the
events in very specific ways it's common to exceed that threshold
(particularly when calling litest_touch_move_to).

Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      bd7b9106
    • Peter Hutterer's avatar
      test: fix the lookup for the timer offset warnings · 2ff0c342
      Peter Hutterer authored 
      

This was changed in 5e25bdfb but the litest
message lookup wasn't changed. Let's do that now and change to a generic
wording we can re-use for other messages.

Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      2ff0c342
  7. May 12, 2020
  9. May 08, 2020
  11. Apr 19, 2020
  13. Apr 18, 2020
  15. Apr 16, 2020
  17. Apr 11, 2020
  19. Apr 06, 2020
  21. Apr 04, 2020
  23. Mar 31, 2020
    • Peter Hutterer's avatar
      tablet: use the AttrPressureRange quirk for tablets too · 72af32c8
      Peter Hutterer authored 
      

The Aiptek 8000U has a pressure offset above our default (%5) but no
meaningful way of detecting that. It doesn't provide distance or BTN_TOOL_PEN
either, so our heuristics can't hook onto anything. BTN_TOUCH is set by this
tablet but not at consistent pressure thresholds.

Work around this by shipping a quirk that ups it to 70. Aiptek
re-uses USB IDs because of course they do, so this applies to more than one
device. Let's see what breaks.

Fixes #462

Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      72af32c8
  25. Mar 30, 2020
  27. Mar 29, 2020
  29. Mar 25, 2020
  31. Mar 23, 2020
  33. Mar 22, 2020