[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
USB keyboard input overrun on EHCI?
This is a problem that I believe has been present for a while, but has
recently (since the new year) become worse:
I have, for a long time, been using a bar code scanner to register books
on LibraryThing, and I've been noticing that my amd64 home workstation
has had a tendency to drop a digit from the injected ISBN from time to
time - I guess it's typically lost one digit from a 10 digit ISBN on
something like every third scan.
To check the scanner, I tried it on a Dell laptop, and, more recently,
on a Pinebook, and it shows no problems on either.
Recently, I bought an Ergodox-EZ keyboard. The BIOS in the keyboard is
able to generate Unicode characters using the standard input method that
is implemented in e.g. GTK 2. This transmits Ctrl-Shift-U, followed by
the hex digits of the Unicode code point, and then a space character.
Running a kernel from (IIRC) January 2nd, this mostly worked fine. Then
I updated to one from February 21st, and now my workstation only manages
to receive a Unicode character once every dozen tries or thereabout.
So, the problem that was already present got a lot worse - and on the
Dell laptop, and on the Pinebook, running kernels built from the same
sources, everything is still fine.
The difference between the systems (apart from two of them being amd64,
and one aarch64) is that the Pinebook has OHCI, the Dell UHCI, and the
(failing) workstation EHCI hardware.
The transmit speed of the keyboard is low. I haven't measured it, but
it looks to be in the 50cps range, meaning 20ms between characters.
(Estimated by watching the keyboard transmit a longer string.)
I'd appreciate hints as to where I should be looking for this problem.
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
Main Index |
Thread Index |