(no subject)

[s2156593@cse.unsw.edu.au (Binh Thai) writes:]

> I have finally worked out where are problem is regarding to the mouse
>driver :-)

Note that I did a bunch of work to make the driver play better with some
flavors of mouse; that would've shown up in 1.6.

> The mouse driver itself is fine. However, the problem occurs at the
>rs232 server. The problem I described in my previous posting was due to the
>fact that the rs232 was reading garbage values, such as a long sequence of
>hex 0 and hex 10, even when the mouse is not moving! this is why the cursor
>is not moving consistantly in MGR.
> My question is now this... Does anyone know why the rs232 server is not
>reading the mouse data correctly? Is there anyway to fix it?

You have to go back and see why your UART is telling the driver that there's
receive data. Either it's because there *is* data streaming in on the port
(if you have an RS-232 breakout box you can check this), or because the UART
status is confused. For the latter, there needs to be both an interrupt (to
create the M_ISR message to start servicing of the port), then the "receive
ready" status needs to be set, and only then will the data port be read and
the data queued for application consumption.

One possiblity is that your mouse has "jitter" and generates an endless
stream of single-bit delta changes. Especially if the UART isn't buffered,
you can then have port overruns, and you start reading garbage from the
port. You can "stat //tty/tty01" (or tty02 for the 2nd COM port) and check
the error counters on the device. A couple overruns are not actually all
that big a deal; the serial protocol is pretty forgiving.

                                                        Andy
Received on Mon Dec 29 15:40:43 1997