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);
>>
