From owner-cvs-all@FreeBSD.ORG Sat Aug 21 18:57:22 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 8FFF116A4CE; Sat, 21 Aug 2004 18:57:22 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9716A43D41; Sat, 21 Aug 2004 18:57:21 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i7LIvFKN062000; Sat, 21 Aug 2004 19:57:16 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Sat, 21 Aug 2004 19:57:14 +0100 From: Brian Somers To: "Justin T. Gibbs" Message-Id: <20040821195714.232ea67f@dev.lan.Awfulhak.org> In-Reply-To: <70CFCC3FCF048C13F0ABFA7B@aslan.scsiguy.com> References: <200408171812.i7HICbLM078769@repoman.freebsd.org> <20040819051134.7f088757@dev.lan.Awfulhak.org> <70CFCC3FCF048C13F0ABFA7B@aslan.scsiguy.com> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org 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 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 18:57:22 -0000 On Thu, 19 Aug 2004 08:43:30 -0600, "Justin T. Gibbs" wrote: > > This breaks my mouse badly - it never syncs now and just flies all over the > > screen doing damage when it's touched. > > Can you provide psm debug output for your mouse? #define DEBUG to 1 > in psm.c. Replied here in case others are seeing the problem. In psm.c 1.79, the setting of sc->mode.syncmask[1] is deferred 'till the first data packet is received in psmintr(). Functionally this doesn't change the behaviour of /dev/psm0... except... After the probe & attach of psm, moused opens /dev/psm and does a few ioctls. One of these is ioctl(MOUSE_GETMODE): if (ioctl(rodent.mfd, MOUSE_GETMODE, &rodent.mode) == 0) { .... cur_proto[0] = rodent.mode.syncmask[0]; /* header byte bit mask */ cur_proto[1] = rodent.mode.syncmask[1]; /* header bit pattern */ } Later, moused says: if (pBufP == 0 && (rBuf & cur_proto[0]) != cur_proto[1]) return 0; /* is there an extra data byte? */ if (pBufP >= cur_proto[4] && (rBuf & cur_proto[0]) != cur_proto[1]) { /* * Hack for Logitech MouseMan Mouse - Middle button * ..... Because syncmask[1] hasn't yet been set (given that you weren't twiddling your mouse between psmprobe() and psmioctl(), we end up with cur_proto[0] == 0x08 and cur_proto[1] == 0x00 and get stuck in both of the if clauses above resulting in somewhat erratic mouse movement. 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]? 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? Also, the use of sc->syncerrors seems broken. It's never reset to zero so the first time it needs to resync after a kvm switch it kind-of works where it drops the first byte in the sequence and continues reading the packet, but after that it'll never work because sc->syncerrors is too big. I'm loathe to change any of this as I don't know anything about the format of these mouse packets and haven't got a big enough variety of mice to test changes on. -- Brian Don't _EVER_ lose your sense of humour !