Web lists-archives.com

Re: [linux-usb-devel] USB mouse autosuspend




On Tue, 3 Jul 2007, Kay Sievers wrote:

> > During a lunch at OLS you mentioned something about watching the LED on 
> > your USB mouse turn on and off as it autosuspended and resumed.  I 
> > don't remember the details, but it sounded peculiar.  Can you explain 
> > what you were referring to?
> 
> Oh, that happens only if there is no driver loaded, and
> CONFIG_USB_SUSPEND is set, the light goes off and gets switched on
> for a few seconds if you press one of the buttons.

Yeah, that's what I thought you said.

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.


In the end, we may be forced not to autosuspend keyboards and mice.  
There are lots of problems.  One is broken hardware, as we see here.  
And ISTR Dave Brownell mentioning a mouse which claimed to support 
remote wakeup but in fact did not.

Another problem is that not all devices will support the wakeup events 
we want.  For instance, a suspended optical mouse can't detect when 
you move it, so it can't send a wakeup request.

A third problem is that users may find it rather disconcerting that the 
LEDs on their keyboards turn off from time to time.

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.

The HP keyboard was the one I tried before.  It often loses keystrokes
when waking up, no matter what the environment.  It does this under 
both UHCI and OHCI, and when either the keyboard, the keyboard and hub, 
or the keyboard and hub and root hub are suspended.  (It also acts 
strangely in that the LEDs go out when the internal hub is suspended, 
not when the keyboard device is suspended.)

The Apple keyboard was better behaved.  The only times it lost
keystrokes were when the keyboard and hub were both suspended, using
UHCI.  Decreasing the polling interval helped, but even at 32 ms it
would still sometimes lose characters.

And I continue to believe that it would be a big mistake to increase 
the CPU overhead by polling more frequently when a device is suspended!

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@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel