From owner-cvs-all@FreeBSD.ORG Sat Aug 21 20:08:05 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E12E16A4CE; Sat, 21 Aug 2004 20:08:05 +0000 (GMT) Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D9EB43D5F; Sat, 21 Aug 2004 20:08:04 +0000 (GMT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.11/8.12.11) with ESMTP id i7LK7ifP006533; Sat, 21 Aug 2004 14:07:44 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Sat, 21 Aug 2004 14:07:44 -0600 From: "Justin T. Gibbs" To: Brian Somers 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> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/isa psm.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2004 20:08:05 -0000 > 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