Michael,

Thanks for your note. Given that it occurred on multiple systems, my
friend and I had thought that it was a driver problem. If you are able to
dig up your fix, we'd be very interested in trying it out!

Should this bug maybe be listed on the web page on the Known Bugs for the
5000/xx port?

Once again, thanks very much, and if your fix turns up, that'd be
excellent. :-)

~Brighten Godfrey
      ________________________________________________________________
            Brighten Godfrey                   godfreyb@bigw.org
                       http://www.bigw.org/~godfreyb/
      ________________________________________________________________

On Tue, 29 Sep 1998, Michael L. Hitch wrote:

> On Sep 29, 10:50pm, Brighten Godfrey wrote:
> > On several Personal DECstation 5000/20s, a friend and I have noticed
> > strange, annoying behavior of the mouse: whenever the system load is high,
> > the mouse acts as though it is clicking, at random. (i.e. you move the
> > mouse over an xterm and it might select text even if you're not clicking
> > the mouse button.) When the system load is low, the mouse acts normally.
> > 
> > Keyboards, mice, and cables have been swapped, and this behavior has been
> > observed on several systems under different window managers. The mouse has
> > model #VSXXX-BB (a hockey puck mouse with two rollers), and the keyboard
> > is model #LK501-AA. We're running NetBSD 1.3.2.
> > 
> > Anyone else note this problem? Any solutions, ideas?
> 
>   This is a bug in the dtop.c driver - it doesn't check correctly for
> "overrun" conditions on the incoming packet data from the serial bus.
> This results in the mouse driver getting out of sync and interpreting
> the wrong data for the mouse button status and movment.  I had a quick
> fix working well enough to detect the overflow and not pass bad data to
> the dtop.c mouse handler, but then tried to switch to using DMA instead
> of polling.  That is sort of working, but not nearly as reliablly as the
> polled method.
> 
>   I'm not sure if I still have the work-around for the polling mode
> around anywhere.  I don't have the pmax at home connected up at the
> moment, which is where I was working on this.  If I still have them and
> can dig them up, I can provide the diffs for this if anyone wants to
> try them out.  I might have to figure out the changes from scratch again,
> assuming I can remember enough about what I did.
> 
>   I've also had some sporadic cases where the PROM switches the device
> address of the mouse and keyboard.  NetBSD assumes the mouse and keyboard
> will be at fixed addresses, and gets very confused.
> 
> Michael
> 
> -- 
> Michael L. Hitch			mhitch@montana.edu
> Computer Consultant
> Information Technology Center
> Montana State University	Bozeman, MT	USA