On Fri, Oct 28, 2011 at 09:50:18AM -0400, John Baboval wrote:
On 10/27/2011 07:56 PM, Kevin O'Connor wrote:
On Thu, Oct 27, 2011 at 04:55:15PM -0400, John
I believe a more robust way to do this would be to first issue a
RESET command, and then flush. That resolves the issue that I am
As for the queue length - this seems like a virtual machine quirk with
timing. The goal of the code is to clear the i8042 buffer which
shouldn't be more than a few bytes. On a real machine, the keyboard
wouldn't have enough time to fill the i8042 before the flush would
remove any characters.
It's possible to increase the timeout, but the increased boot time can
be annoying for users on real hardware without a ps2 port. Another
option may be to change the code so that it reads and discards
continuosly for 1ms - that way it can clear however many bytes are
present, but still move on quickly if the port isn't responding.
Since the flush breaks out of the loop when the buffer is empty,
increasing the count shouldn't increase boot times except in cases
where the keyboard would have been broken anyway.
Many real machines use USB keyboards or don't have a keyboard at all.
Granted, they usually emulate the i8042 anyway, but we've run into
enough boards without a functional i8042 that this needs to work
I like the time based mechanism, though. The reset and
for <buffer size> iterations was still a race between the loop and
the key repeat or angry user.
The goal of the flush isn't to get rid of keyboard keys, but to get
rid of lingering responses from commands sent to the i8042. A
spurious key event won't cause an issue during init, but a stale
response to an i8042 command from a previous session will confuse
I will re-code it as a time-based loop instead of a
count based loop
and re-submit it.
I'm also trying to figure out how my buffer is getting filled so early.
Okay - thanks.