On 5/27/08, Rick C. Petty <[EMAIL PROTECTED]> wrote: > On Tue, May 27, 2008 at 02:28:26PM -0700, Maksim Yevmenkin wrote: > > > > well, i just took a brief look at atkbd(4). specifically one function > > - wait_while_controller_busy(). this function polls status every > > KBDC_DELAYTIME (20) usec with retry count of 5000. so, just this > > function alone can give up to 100 msec delay. keep in mind that > > wait_while_controller_busy() is apparently called every time driver > > need to talk to the hardware. i can see how we could delay kernel for > > 400 msec or even more. > > I'm not sure why we retry 5000 times. 100ms seems like a long time to > block the entire kernel. Is there any reason we can't spawn a kernel > thread to deal with the waits? I recommend that we also reduce the > timeouts to at most twice what the spec states.
all great ideas. please send in the patches and i will be happy to review and commit them for you. > How come this doesn't happen when other keys are pressed? Just when the > console is flipped. Perhaps because it tries to set the LEDs first? like i said, i suspect delay happens only when driver needs to send command to the keyboard. that is what happens when you press num/scroll/capslock. thanks, max > > > -- Rick C. Petty > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
