--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> I'm not sure whether 'hz' can change during kernel runtime - if not a
> global value initialized at attach time would do.

Ok, it can not change. So now we are left with two options: leave it as in
my patch and hope for the compiler to recognize the const'ness and optiomize
it completely away for archs where hz is a compile time constant, or make
it a static global variable, computed once at attach time of the first
mouse (see patch below). Not sure if it's worth the effort.

Martin

P.S.: any clever ideas how to get rid of the stupid kernel thread
doing the reset will be appreciated. Tested & know working suggestions
that do not block interrupts during the reset only, please.

--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="pms_mono_const_hz.patch"

Index: pms.c
===================================================================
RCS file: /cvsroot/syssrc/sys/dev/pckbc/pms.c,v
retrieving revision 1.8
diff -c -u -r1.8 pms.c
--- pms.c	2002/07/10 02:05:25	1.8
+++ pms.c	2002/08/30 18:53:18
@@ -107,6 +107,13 @@
 void	pms_power __P((int, void *));
 #endif /* !PMS_DISABLE_POWERHOOK */
 
+/*
+ * Max. delay we consider "normal" between two bytes in the same
+ * protocol packet, rounded up to a value distinguishible by
+ * 'mono_time' resolution.
+ */
+static unsigned int max_delay = 0;
+
 const struct wsmouse_accessops pms_accessops = {
 	pms_enable,
 	pms_ioctl,
@@ -205,6 +212,27 @@
 
 	printf("\n");
 
+	/*
+	 * Calculate the maximum delay between two bytes in one packet.
+	 *
+	 * Empirically, the delay should be about 1700us on a standard
+	 * PS/2 port.  I have seen delays as large as 4500us (rarely)
+	 * in regular use.  When using a confused mouse, I generally
+	 * see delays at least as large as 30,000us.  This serves as
+	 * a rough geometric compromise. -seebs
+	 *
+	 * The thinkpad trackball returns at 22-23ms. So we use
+	 * 25ms. In the future, I'll implement adaptable timeout
+	 * by increasing the timeout if the mouse reset happens
+	 * too frequently -christos
+	 */
+
+	if (max_delay == 0) {
+		/* round 25ms up to next value of hz granularity */
+		max_delay = (25*hz+999)/1000;	/* calc ticks */
+		max_delay *= 1000000/hz;	/* convert to usec */
+	}
+
 	/* Flush any garbage. */
 	pckbc_flush(pa->pa_tag, pa->pa_slot);
 
@@ -509,24 +537,13 @@
 		return;
 	}
 
-	microtime(&sc->current);
+	sc->current = mono_time;
 	if (sc->inputstate > 0) {
 		struct timeval diff;
 
 		timersub(&sc->current, &sc->last, &diff);
-		/*
-		 * Empirically, the delay should be about 1700us on a standard
-		 * PS/2 port.  I have seen delays as large as 4500us (rarely)
-		 * in regular use.  When using a confused mouse, I generally
-		 * see delays at least as large as 30,000us.  This serves as
-		 * a rough geometric compromise. -seebs
-		 *
-		 * The thinkpad trackball returns at 22-23ms. So we use
-		 * 25ms. In the future, I'll implement adaptable timeout
-		 * by increasing the timeout if the mouse reset happens
-		 * too frequently -christos
-		 */
-		if (diff.tv_sec > 0 || diff.tv_usec > 25000) {
+
+		if (diff.tv_sec > 0 || diff.tv_usec > max_delay) {
 			DPRINTF(("pms_input: unusual delay (%ld.%06ld s), "
 			    "scheduling reset\n",
 			    (long)diff.tv_sec, (long)diff.tv_usec));

--PNTmBPCT7hxwcZjr--