psm: Fix three finger tap on elantech v4 touchpads

[rwahlberg]

Elantech touchpads using the version 4 packet format have issues with tapping with more than two fingers. Tapping with three fingers to generate a middle click event generates multiple clicks.

This has been reported a couple of times in the FreeBSD forums:

• https://forums.freebsd.org/threads/libinput-weird-three-finger-detection.87115/
• https://forums.freebsd.org/threads/tap-to-click-on-touchpad-is-registering-as-multiple-clicks.97867/

Debug output (sysctl debug.psm.loglevel=5) gives the following output (format and comments by me):

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 5

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 6

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 6
Jul 26 11:01:45 rtp kernel: elantech: finger 1: down [753, 790], 27, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 2: down [2117, 1328], 31, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 3: down [1313, 1400], 32, 4, 0

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 1: down [747, 796], 27, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 3: down [1313, 1400], 32, 4, 0

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 2: down [2117, 1328], 31, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 3: down [1313, 1400], 32, 4, 0

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 1: down [747, 797], 27, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 2: down [2117, 1328], 31, 4, 0
# Tap event incorrectly generated here

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 1: down [747, 797], 27, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 3: down [1313, 1399], 32, 4, 0

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 2: down [2117, 1328], 31, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 3: down [1313, 1398], 32, 4, 0

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 1: down [747, 797], 27, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 2: down [2117, 1328], 31, 4, 0
# Tap event incorrectly generated here

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 1: down [747, 797], 27, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 3: down [1312, 1397], 32, 4, 0

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 2: down [2116, 1328], 31, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 3: down [1312, 1397], 32, 4, 0

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 1: down [747, 797], 27, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 2: down [2115, 1328], 31, 4, 0
# Tap event incorrectly generated here

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 7
Jul 26 11:01:45 rtp kernel: elantech: finger 1: down [747, 797], 27, 4, 0
Jul 26 11:01:45 rtp kernel: elantech: finger 3: down [1312, 1397], 32, 4, 0

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 5
# Tap event correctly generated here

Jul 26 11:01:45 rtp kernel: elantech: ipacket format: 5

The issue seems to be that the format 7 (motion) packets generate a tap event whenever finger 3 is not part of the event. However, the packet should be interpreted as a position update, not an update to which fingers are present. That is what format 5 (status) packets are for.

For motion packets we should reuse the previous state and then apply the update in the packet instead.

[wulf7]

LGTM