On Tue, Mar 23, 2021 at 05:52:10PM +0100, Ulf Brosziewski wrote:
> Thanks for the report. The logging shows that the contacts are recognized,
> so we have indeed to look at the filters of the driver. Two filters are
> relevant here: The first and essential one checks whether the duration of
> a contact exceeds the "tapping timeout" (180ms by default). The second
> one discards contacts which are "too far" away from their initial position
> (in order to distinguish a short movement sequence from a tap gesture).
>
> Could you test whether the patch below helps, at least on the Thinkpad?
> It makes the second filter less restrictive (plainly, it won't apply to
> multi-finger taps).
That diff makes double and triple taps work reliably on the Thinkpad!
No idea if relevant but two finger scroll also still works, regardless
of the `moues.tp.tapping' value.
Will try the Pinebook later.
> As to the timeout, the "timestamp" values in the Pinebook output show some
> large gaps. Are the sequences complete?
In what sense? I copied the text as-is from `tail -f /var/log/messages'
explicitly hitting enter between each tap exercise to separate them.
So each paste should be as they came out of the driver, without
intermangled lines from previous or next tap exercises.
> Do you have the habit of tapping very slowly?
I'd say those are fast taps, I can hardly do them any faster;
certainly no resting on the touchpad.
Have you observed timing-related problems on that machine?
Yes, but only with playing audio: it's too fast and high pitched,
kettenis said there might be a clock or rkiis(4) related problem.
I couldn't come up with anything in that regard so far.
> The four-digit numbers in the log lines represent the current low-precision
> time in milliseconds modulo 10000. For example, this sequence
> [wsmouse0-in][4275] abs:636,444 mt:0x01:0
> [wsmouse0-in][4556] mt:0x00:-1
> would indicate that the duration of the contact was about 4556-4275
> milliseconds, which exceeds the default timeout by far. If this happens
> often, there might be some hardware problem.
>
> You could try to mitigate a timeout problem by increasing the threshold
> to, e.g., 250ms by issuing the command
> $ doas wsconsctl mouse.param=173:250
> but I would recommend to keep it within reasonable limits.
$ doas wsconsctl mouse.param=173:250
wsconsctl: invalid input (param)
> Index: dev/wscons/wstpad.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/wscons/wstpad.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 wstpad.c
> --- dev/wscons/wstpad.c 21 Mar 2021 16:20:49 -0000 1.28
> +++ dev/wscons/wstpad.c 23 Mar 2021 09:09:42 -0000
> @@ -657,14 +657,8 @@ wstpad_is_tap(struct wstpad *tp, struct
> struct timespec ts;
> int dx, dy, dist = 0;
>
> - /*
> - * No distance limit applies if there has been more than one contact
> - * on a single-touch device. We cannot use (t->x - t->orig.x) in this
> - * case. Accumulated deltas might be an alternative, but some
> - * touchpads provide unreliable coordinates at the start or end of a
> - * multi-finger touch.
> - */
> - if (IS_MT(tp) || tp->tap.contacts < 2) {
> + /* Try to distinguish one-finger taps from short movements. */
> + if (tp->tap.contacts == (tp->ignore ? 2 : 1)) {
> dx = abs(t->x - t->orig.x) << 12;
> dy = abs(t->y - t->orig.y) * tp->ratio;
> dist = (dx >= dy ? dx + 3 * dy / 8 : dy + 3 * dx / 8);
>
