On Wed, 25 Feb 2009, Sarah Sharp wrote: > > Does your tool also test remote wakeup? In many cases selective > > suspend is useless without it. > > The tool prompts the person to actively use the USB device after it > successfully autosuspended. It does mention that some devices have > remote wakeup and they could activate it by clicking a button on their > mouse, etc. Remote wakeup is enabled by the kernel by default, correct? Yes; it is enabled by default for all devices that support it. I guess the tool could check whether power/wakeup was empty; if it is then the device doesn't support remote wakeup. > I haven't thought too much about the remote wakeup side. Are there > pitfalls for devices that use remote wakeup that we've seen? I want to > be sure that when we get a report of a good device from a user that the > device won't break when woken up in a different fashion (and thus > shouldn't be on the whitelist). As far as I know, the only pitfalls related to remote wakeup are: Some devices don't send a wakeup signal when you would think they should; Some devices don't work they way you would expect them to after signalling a remote wakeup. Of course, some devices don't work at all after resuming, but that's a separate matter. Which reminds me: There is a quirks flag for devices which always require a reset after a resume. Your tool could test for this requirement. If the device doesn't work right away after resuming, but it does work after a reset, then it should have the RESET_RESUME quirk. (And this reminds me even more: When the kernel does a reset-resume, it also does Set-Interface even for interfaces that were already in altsetting 0. This seems like a waste of time, and even worse, a possible detriment since many devices don't support Set-Interface correctly. I need to change this...) > I'm aware that Oliver found some USB mice that would wakeup only when a > button was clicked but not when they were moved. I'm not sure whether > such a mouse should be added to the whitelist; on one hand auto-suspend > does work in a limited sense, but the user might notice a new "failure" > and assume they need to change their mice batteries. If this > semi-broken device shouldn't be added to the whitelist I could add > special prompts for HID devices. IMO such a mouse should not be added to the whitelist. > Are there any other examples where remote wakeup might be an issue? Yes indeed. Testing done a couple of years ago showed that most keyboards don't retain keystrokes properly when they do a remote wakeup. That is, if the keyboard is suspended and you type on it to wake it up, one or more of your keystrokes will get lost. Only a few of the keyboards we tried didn't have this flaw; IIRC Apple keyboards worked well. > > At the moment there can't be very many devices to test. Only a > > handful of USB drivers support autosuspend. > > Yes, it's true that not many drivers implement autosuspend. However, I > think the USB HID auto-suspend support will be merged soon. Jiri pulled > Oliver's final auto-suspend patch into the HID tree on Jan. 16th to pull > into -next; would that mean it gets into 2.6.30? (I'm still slightly > confused about what the role of the -next tree.) That's right. Things in the -next tree are scheduled to be included in the mainstream during the next big merge window, which occurs just after the next release (which will be 2.6.29). Hence they will get into the release following the upcoming one, i.e., into 2.6.30. > I do want users to be able to enable auto-suspend for all the devices > that support it. I had hoped the tool would have some of the same > effect powertop has; if a developer finds that the driver for their > device doesn't support auto-suspend, they may might be motivated to add > auto-suspend support to the driver themselves, or try to get the driver > maintainer to fix it. Making USB power management visible to the > average user was the goal of this tool. This is a great idea and it's good to see you working on it. Can you make the tool available in some forms other than a Git download? Perhaps an RPM source file or even just a tarball? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
