kern/57874: pms(4) completely unusable after r. 1.76 change to synaptics.c

[david%gutteridge.ca@localhost]

>Number:         57874
>Category:       kern
>Synopsis:       pms(4) completely unusable after r. 1.76 change to synaptics.c
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 23 22:55:00 +0000 2024
>Originator:     David H. Gutteridge
>Release:        10.0_RC3/i386
>Organization:
The NetBSD Foundation
>Environment:
>Description:
After r. 1.76 was committed to synaptics.c, this made my (yes, rather
old) trackpad and physical buttons completely unusable on an LG X110.
This is a regression in NetBSD 10.x vs. 9.3_STABLE.

Reverting part of the r. 1.76 change restores all basic functionality
(both physical buttons register clicks, trackpad registers single
finger movement), specifically, doing this:

RCS file: /cvsroot/src/sys/dev/pckbport/synaptics.c,v
retrieving revision 1.82
diff -u -r1.82 synaptics.c
--- synaptics.c	5 Sep 2023 05:55:12 -0000	1.82
+++ synaptics.c	23 Jan 2024 20:25:23 -0000
@@ -1420,6 +1420,7 @@
 			nsp.sp_z = psc->packet[2];
 		}
 
+#if 0
 		/*
 		 * Check if the x and y are non-zero that they
 		 * are within the bounds of the trackpad
@@ -1440,6 +1441,7 @@
 			    nsp.sp_x, nsp.sp_y);
 			return;
 		}
+#endif
 
 		nsp.sp_finger_count = pms_synaptics_get_fingers(psc,
 		    nsp.sp_w, nsp.sp_z);

There seems to be more than one issue involved here. Part of it seems
simply that the physical button clicks are getting caught in the
"check if x and y are non-zero" block and being discarded.

There is other strangeness/regression in that the bounds of the
trackpad are calculated completely differently in 9.3 vs. 10.0 RC3.
(A probably related PR in this regard is kern/57794, noting the same.)
It's not even possible to change them all back to the values in 9.3
using sysctl -w. That is, I can make a change to one of them, I will
get a response the change was made, and then it is immediately reset
by the driver back to its (wrong?) value. (This seems dependent on
which parameter. I am still looking at this.)

Dave

>How-To-Repeat:
As above.
>Fix:
Hack/workaround as above, disable that block of code.