Kazutaka YOKOTA wrote:
> While we are carrying out the reset/initialization sequence, the mouse
> pointer will be frozen on the screen. The keyboard input may not
> respond in a timely fasion because the PS/2 mouse and the AT keyboard
> share the same I/O port. Then, I suspect our user may feel uneasy and
> think the entire FreeBSD is frozen...
The keyboard freeze seems problematic; can you decouple the
reset vs. the reset complete notification, by keeping a flag
("currently resetting") that the interrupt handler can look
at? This kind of goes with your next observation:
> What do you think the average user will do in such situation? It is
> quite likely that s/he will wiggle the mouse (rather frantically?) to
> see if the mouse is dead, won't he? I am not sure our initialization
> sequence is robust enough to not be disturbed by this.
Yes, wiggling the mouse to make it work is the natural thing
for someone to do...
> If disable/enable sequence, which is lot simpler and takes considrably
> less time, can correct the sync problem, I think it will be better.
It looks to me as if the mouse is automatically enabled by
default after a reset? If this is true, then doing a disable
then a reset will result in the next mouse packet coming in
on a correct boundary. It makes the reset a tiny bit more
complicated, but makes the results more deterministic.
I don't know what to tell you, if the keyboard goes away during
the reset process: it seems counter-intuitive, and it means you
can't use keyboard shortcuts to get to a mouse "control panel"
to fix the problem manually... 8-(.
I think if that's unavoidable, a simple comment to that effect
in the code would save you loads of grief later.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
