Skip to content

WIP: Touchpad: Add physical button debouncing

Jacob Moroni requested to merge jakemoroni/libinput:master into main

Physical (mechanical) touchpad buttons, like all mechanical switches, have the potential to bounce during state changes, which can end up resulting in spurious clicks and releases.

Currently, there is debounce logic in place for regular pointer devices which are handled by "fallback_dispatch", but not for touchpad buttons.

With some modifications, I was able to reuse the existing debounce logic to handle touchpad buttons as well.

This consisted of two main changes:

  • Modification of the existing debounce code in evdev-debounce.c to remove the dependency on struct fallback_dispatch. Now, all debounce routines accept a pointer to struct debounce rather than struct fallback_dispatch. This wasn't really a functional change, but required moving some code around and creating a new header. The only interaction between the debounce code and fallback dispatch directly was to get the evdev_device and the current/last button states, so it wasn't too bad. Now, the evdev_device and a pointer to some operators to obtain the button states are provided to init_debounce.

  • Modification to the tp_post_physical_buttons routine to send the button events through the debounce filter instead of calling evdev_pointer_notify_physical_button directly, plus some other small changes to tie it all together.

I have tested these changes with a Dell Latitude 5580 and it works as expected.

By performing some manual click tests, I'm able to see the button bouncing via libinput record, but the extra clicks are now filtered.

Also, I can see in the logs that "spurious button debouncing" is being enabled, as expected.

However, as it stands, there are still some issues with these changes:

  • Some of the tests are currently failing.

  • Touchpad devices are still excluded from the existing debounce tests, as the tests fail otherwise.

I'm submitting this merge request mainly to get feedback on the approach. I expect there will have to be some changes.

See issue #329

Merge request reports