cvs commit: src/sys/isa psm.c

[Justin T. Gibbs]

> I'm not sure why these changes (psm 1.79) would have made things work for
> you - perhaps you're booting your machine with the KVM pointing somewhere
> else and as a result, avoiding doing the data read in psmprobe() is fixing
> the problems result?  If so do we need to do a similar tweak to moused to
> defer the recording of cur_proto[1]?

As explained in the commit message, the reason this helps is because the
KVM emulation gets the sync bits wrong if you explicitly ask for a data
packet.  It doesn't matter if you have the system selected or not.

As for why it works for me and many others, I can only assume that the
sync bits turn out to be zero.  I have verified this on my system.

Since the psm driver performs sync detection and out-of-sync discard,
it seems to me that moused should not be trying to do the same thing.
Outside of doing that, changing the PSM driver to export a zero
syncmask anytime NEED_SYNC is set will ensure that moused doesn't
get confused.

Index: psm.c
===================================================================
RCS file: /usr/cvs/src/sys/isa/psm.c,v
retrieving revision 1.79
diff -d -u -r1.79 psm.c
--- psm.c	17 Aug 2004 18:12:37 -0000	1.79
+++ psm.c	21 Aug 2004 20:06:40 -0000
@@ -1752,6 +1752,10 @@
     case MOUSE_GETMODE:
 	s = spltty();
         *(mousemode_t *)addr = sc->mode;
+        if ((sc->flags & PSM_NEED_SYNCBITS) != 0) {
+            ((mousemode_t *)addr)->syncmask[0] = 0;
+            ((mousemode_t *)addr)->syncmask[1] = 0;
+        }
         ((mousemode_t *)addr)->resolution = 
 	    MOUSE_RES_LOW - sc->mode.resolution;
 	switch (sc->mode.level) {

> BTW, while I was in there I noticed this:
> 
>     if (sc->config & PSM_CONFIG_NOCHECKSYNC)
>         sc->dflt_mode.syncmask[0] = 0;
>     else
>         sc->dflt_mode.syncmask[0] = vendortype[i].syncmask;
>     if (sc->config & PSM_CONFIG_FORCETAP)
>         sc->mode.syncmask[0] &= ~MOUSE_PS2_TAP;
>         ^^^^^^^^^^^^^^^^^^^^
>     sc->dflt_mode.syncmask[1] = 0;      /* syncbits */
>     sc->mode = sc->dflt_mode;
>     sc->mode.packetsize = vendortype[i].packetsize;
> 
> which looks somewhat bogus as the whole sc->mode structure is overwritten
> two lines later!  Perhaps it should be dflt_mode.syncmask[0] that's tweaked?

Yes, it is bogus.

> Also, the use of sc->syncerrors seems broken.  It's never reset to zero...

Its reset to zero if a mouse packet isn't completed before a packet
timeout fires.  It seems that the counter should be reset in other cases
too, but I would need to study the driver further before changing that.
is not received withing

--
Justin