Re: USB keyboard input overrun on EHCI?

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

Brian Buhrow <buhrow%nfbcal.org@localhost> writes:

> 	hello.  My recollection may be slightly wrong here since I'm
> still running NetBSD-5 in most cases, but my understanding is that
> ehci(4) connected devices are all USB-2.0 and for slower devices, the
> uhci(4) or ohci(4) hub drivers provide service.

Ah, it's not different hardware as much as different protocol choices?
I do notice that on the two laptops, where the keyboard works well,
there are "handing over full speed device" messages when connecting it,
whereas on the workstation, where it can overrun the input, this does
not occur.  Maybe I should go through the BIOS configuration with a fine
tooth comb, to see if there's something there that limits devices in
what level of USB functionality they can negotiate?

Meanwhile, I think I've found something more interesting (thanks to
debugging guidance from riastradh@): in /sys/dev/usb/ukbd.c, there is
this block of code, in the interrupt handler:

	if ((sc->sc_flags & FLAG_DEBOUNCE) && !(sc->sc_flags & FLAG_POLLING)) {
		/*
		 * Some keyboards have a peculiar quirk.  They sometimes
		 * generate a key up followed by a key down for the same
		 * key after about 10 ms.
		 * We avoid this bug by holding off decoding for 20 ms.
		 */
		sc->sc_data = *ud;
		callout_reset(&sc->sc_delay, hz / 50, ukbd_delayed_decode, sc);
#ifdef DDB
	} else if (sc->sc_console_keyboard && !(sc->sc_flags & FLAG_POLLING)) {
		/*
		 * For the console keyboard we can't deliver CTL-ALT-ESC
		 * from the interrupt routine.  Doing so would start
		 * polling from inside the interrupt routine and that
		 * loses bigtime.
		 */
		sc->sc_data = *ud;
		callout_reset(&sc->sc_delay, 1, ukbd_delayed_decode, sc);
#endif
	} else {
		ukbd_decode(sc, ud);
	}

If I read this correctly, the first bit says "for certain keyboards, we
have to wait 20ms after a change before accepting it, because it may be
a switch bounce, which will have cleared by then".  Fine - not relevant
to me.  The next bit, though, is.  It says that if we're the console
keyboard, we always wait 10ms, and then handle the keyboard event (if it
is still relevant).  This means, though, that if we get the next event
from the keyboard within 10ms of the last one, we may lose an event.

I haven't carefully measured the output from my new keyboard when it's
generating sequences of keypresses, but by just eyeballing it, I've
estimated it to be in in the vicinity of 50cps, or 10ms per event - and
a difference between the workstation that's being overrun and the two
laptops that aren't, is, of course, that on the former my new keyboard
is the console keyboard.

I'll test a kernel without that "else if" block tonight.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay