Re: [linux-usb-devel] USB mouse autosuspend
- Date: Wed, 04 Jul 2007 08:15:08 +0200
- From: Robert Marquardt <marquardt@xxxxxxxxxxxxx>
- Subject: Re: [linux-usb-devel] USB mouse autosuspend
Jiri Kosina schrieb:
> 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.
If a USB device suspends because te bus goes idle then it is allowed to
draw 2.5 mA if it is a 500 mA device and supports remote wakeup. All
others are only allowed considerably less. LEDs start at 10 mA (not the
cheap ones). So the LED going off means the device tries to behave.
> 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.
Definitely. i have a flagship Cherry keyboard here which needs seconds
if i send it some basic HID commands like reading the device strings
>> 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).
Apple USB products tend to have better quality. They get tested
routinely to work with MacOS and Windows. Often enough they are quirky
to support Windows.
BTW keyboards with hubs are usually full-speed devices whereas other
keyboards are usually low-speed. Newer mice are also full-speed to be
attractive to gamers. Maybe the resume problem hides in that area.
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: