| A while back someone reported having keyboard repeat problems, but the
| general repsonse from people was that they weren't using their console
| keyboards. 
|
| I have noticed the key repeat problem on the keyboard of my U10. It
| makes it almost impossible to put my NetBSD system back together again
| whenever I break it. I have also noticed two other things 1) the com
| port drivers are for a 16550 chip, and so they should be the same as in
| NetBSD/i386 and therefore well tested and reliable and 2) the PROM seems
| to be still trying to control the keyboard. Stop-A will not get me
| access to OF under NetBSD and some documentation somewhere seemed to
| indicate that this was because OF was stealing the Stop-A key sequence
| and another key sequence was used by NetBSD to activate OF instead.
|
| What I want to know is, does this sound correct (or even coherent) and
| is it likely that this problem is caused by OF and NetBSD fighting over
| the keyboard's serial port and messing it up?

Ah yes, the console problem...

1) The problem only occurs if you use a kernel driver for input an the
firmware for output.

2) It occurs on the com driver as well as kbd at zstty, but not with
the zskbd driver.

3) The PROM does not use interrupts but the kernel does.

I suppose it is possible that the firmware polls the input device 
whenever it runs, but I find that unlikely.  However, I suppose 
it is possible.  Determining if it's actually happenning is going
to be difficult other than by actually fixing the problem.  

I suppose if we could guarantee that the driver took an interrupt 
and grabbed the input before the firmware could get it then the
problem might go away.  Or registering a service routine to let
the kernel handle the PROM's input might also help.

However, since the kbd_zs driver does not suffer from this problem,
I think it's much more likely to be some issue involving latencies
scheduling callouts to handle the TTYs rather than competition between
the firmware and a driver.

Now, the Stop-A problem is probably a different issue that was
cause when the com driver was converted to use cnmagic().  It's
probably conflicting with the sunkbd driver.  You should check
to see what the hw.cnmagic sysctl variable is set to.

Eduardo