Re: [linux-usb-devel] USB mouse autosuspend
- Date: Tue, 3 Jul 2007 18:54:04 +0200 (CEST)
- From: Jiri Kosina <jikos@xxxxxxxx>
- Subject: Re: [linux-usb-devel] USB mouse autosuspend
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?
It could be that only the light goes on for a few seconds (Alan, are you
sure that the power would not suffice?), but the mouse is not issuing any
wakeup request. Kay, if you have only usb hid unloaded but the rest of USB
infrastructure is there, we could easily see from usbmon output whether
the mouse really did issue a wakeup request.
> 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
Sure, as we have been talking about it on OLS. Added Oliver to CC.
> 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
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
> 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.)
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. Oliver, I currently think that usb hid autosuspend would bring much
more problems than it would give us.
> The Apple keyboard was better behaved. The only times it lost
> keystrokes were when the keyboard and hub were both suspended, using
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).
> 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!
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.
To unsubscribe, use the last form field at: