Date: Sat, 21 Aug 2004 19:57:14 +0100 From: Brian Somers <brian@Awfulhak.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/isa psm.c 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Aug 2004 08:43:30 -0600, "Justin T. Gibbs" <gibbs@scsiguy.com> 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 <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040821195714.232ea67f>