On 3/23/21 8:31 PM, Klemens Nanni wrote: > 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!
The patch is waiting for an OK ;-) As to the parameter number, it's 137, not 173. Sorry for that misinformation. > 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); >>