>> 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?
No, the mouse is disabled after reset. We need to explicitly
enable it. This will be done during our re-initialization
sequence.
>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.
Yes. We can expect we get the packet boundary right after
the reset command followed by the enable command. And that's why
we shall reset the "error counter" to zero after reset/reinitialize.
>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-(.
The keyboard won't be inaccessible during the mouse reset sequence.
Its data won't be lost (in theory). But, you just feel the keyboard
is not responding quickly...
Anyway, I shall make a patch and we test it to see how it behaves...
>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
