On Fri, 3 Aug 2007, Jiri Kosina wrote: > What I have been seeing with both these keyboards was: if connected to > UHCI controller, root hub not auto-suspended, as soon as they got > autosuspended, and keys were pressed on them rapidly, very often some > keypressess got lost. I didn't experience this on OHCI, but I remember > Alan saying that he triggered it on OHCI too, right? > > Seemed like a timing issue - by lowering the polling timeout we were able > to make things much better, but that of course costs us more power etc. > and it's even not sure if it is an ultimate solution.
Jiri and I ran a few tests at OLS, and we each did additional testing on our own. We looked at a small selection of keyboards; the ones I tested were by Apple and HP. Some keyboards had embedded hubs and others didn't. Some of our testing was with the keyboard behind an external hub. Sometimes only the keyboard controller was suspended, sometimes the controller and the embedded hub were, sometimes the external hub and everything downstream of it were, and sometimes the root hub was. We tested with both UHCI and OHCI -- I may even have done some tests with EHCI and a high-speed hub, I don't remember now. The end result was that some scenarios worked more reliably than others. There were lots of variables and it was hard to tie overall behavior with system settings. It did seem that in situations where the topmost suspended device was plugged into a UHCI root hub, increasing the the root hub's polling rate helped. But it didn't always help, and in any case we certainly don't want to change a kernel timer from 250 ms to 32 ms whenever a device is suspended! The bad behavior we observed, as Jiri described, was that rapid typing on a suspended keyboard would often cause one or more of the keystrokes to be lost. The probability of this happening varied with the circumstances, but I don't think I ever found a combination that was 100% reliable. It could well be a timing issue, or buffering -- there's no real way to know. An additional drawback to autosuspend for keyboards is the fact that the NumLock, CapsLock, etc. LEDs go out. We didn't test any mice (at least, I didn't). However it has been reported that while some suspended mice will send wakeup requests when they are moved, others won't. Certainly an optical mouse won't. All in all, it appears that the simplest and most user-friendly approach is just not to autosuspend keyboards and mice. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
