On Tue, 3 Jul 2007, Jiri Kosina wrote: > On Tue, 3 Jul 2007, Alan Stern wrote: > > > It's totally bogus! With no driver loaded, the mouse won't be enabled > > for remote wakeup. Consequently it should never be resumed, no matter > > what you do to it. If it does send a wakeup request then the mouse is > > buggy. Conversely, if the mouse doesn't get resumed then it shouldn't > > draw enough current to turn on an LED. Either way, the mouse isn't > > working right. > > Kay, by "no drivers loaded" you mean only usbhid driver unloaded, or also > usb host/core drivers?
I think Kay meant usbhid wasn't loaded. Kay, is that right? > It could be that only the light goes on for a few seconds (Alan, are you > sure that the power would not suffice?), I'm not sure of the exact value, but an LED typically uses around 20 mA of current. Something on that order, anyway. However a suspended USB device is limited to 5 uA or less, at least 1000 times smaller. Devices are allowed to exceed that limit for short periods of time, but averaged over a second the total current usage must be very small. A properly functioning bus-powered device could never keep an LED lit up for two seconds during suspend. > > Yet another problem is that devices don't always work reliably when > > they resume. Jiri, I did some more testing with two different USB > > keyboards, one from HP and one from Apple. They each have an internal > > hub. > > I see. Would you have by chance any possibility also to test keyboard with > internal hub on your notebook, if it will also get stuck as in the case we > have seen with my keyboard when it was not connected through the external > hub? I'll try. However I suspect the odd behavior was caused by old hardware in my laptop. (Of course, other people may have similar problems with their old hardware...) > OK, it seems that vendors of usb keyboards probably rely too much on fact > that the keyboards could be quite slow and flaky without anyone > complaining under normal load, and therefore implement the things very > badly. Not to mention that they probably never test the resume response because Windows doesn't do runtime suspend. > > The Apple keyboard was better behaved. The only times it lost > > keystrokes were when the keyboard and hub were both suspended, using > > UHCI. > > Which is absolutely the opposite situation to what we have observed on my > uhci-based notebook! (i.e. the resume worked well if and only if the root > hub *was* suspended). No -- the Apple keyboard also seemed to do okay when the root hub was suspended. The problems occurred when the root hub wasn't suspended and the internal hub was. But it is still different from what we saw with your keyboard attached to an unpowered hub. That had no problems at all. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
