Date: Sat, 21 Aug 2004 14:07:44 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Brian Somers <brian@Awfulhak.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/isa psm.c Message-ID: <2EBB6525AF8622BD86E3D2C9@aslan.scsiguy.com> In-Reply-To: <20040821195714.232ea67f@dev.lan.Awfulhak.org> References: <200408171812.i7HICbLM078769@repoman.freebsd.org> <20040819051134.7f088757@dev.lan.Awfulhak.org> <20040821195714.232ea67f@dev.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2EBB6525AF8622BD86E3D2C9>