>o If you are going to reset, disable and drain the input
> queue before you do it; this will make the mouse lose
> buffered data, making a partial send with a disable
> in the middle not resume (e.g. it is no longer an
> issue for you).
Don't worry. I was going to do this :-)
>o Because reinitialize can take a relatively _long_
> time, split the "reset" and "reset" complete operations
> across a tsleep() (or msleep) so that the rest of the
> system doesn't stall (I think the number I saw was 2
> seconds?!?). If you get an interrupt on the reset
> complete because it always sends data, then that's not
> a real issue: the tsleep becomes a guarantee, rather
> than a requirement.
Yes, we need to be careful about this. As the AT keyboard data and the
PS/2 mouse data must read from the same keyboard controller port on
the motherboard, we want to remove the mouse data from the keyboard
controller port as soon as it arrives, otherwise the keyboard data
will be blocked.
>o You may want to implement a rate throttling mechanism;
> init will stop respawning a getty on a port, if it is
> exiting too rapidly, while inetd will rate limit the
> number of connection attempts a second, as well. I
> guess you probably don't want to disable it, ala init,
> but limiting the number of reinitialize/resets per
> interval would address the "too expensive" and "reset
> causes additional resync errors" cases.
We are not running getty on the mouse port. So, we don't need
to worry about this.
Kazu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
