On Wed, Feb 25, 2009 at 09:50:20PM +0200, Alan Stern wrote: > 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. Sure. I guess I don't see why selective suspend would be useless without remote wakeup. For example, my USB camera on my eeepc doesn't have remote wakeup, but it auto-suspends fine. When I'm not using it, I want it to be auto-suspended. > > 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. Sure, the tool could set the RESET_RESUME quirk and re-test if the device doesn't work after a host-initiated resume. Would the tool have to reload the USB core? Or just the driver for that device? I'm unclear how to dynamically add quirks flags, and Documentation/usb/hotplug.txt isn't much help. I can see that I have a modules.usbmap in /lib/modules/2.6.xx/ but that doesn't seem to have any of the PID:VIDs listed as needing reset resume in drivers/usb/core/quirks.c. > (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. Ok, it sounds like I need some specific prompts to the user as to how they need to test their HID device. > > 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. That's too bad. At least the HID support will be help users who plug in USB mice into their laptops to get better battery life. > > 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? The gitweb on moblin.org does provide compressed versions of the latest commit on a tree. Pick your format of choice: http://git.moblin.org/cgit.cgi/usb-pm-tool/snapshot/usb-pm-tool-master.zip http://git.moblin.org/cgit.cgi/usb-pm-tool/snapshot/usb-pm-tool-master.tar.gz http://git.moblin.org/cgit.cgi/usb-pm-tool/snapshot/usb-pm-tool-master.tar.bz2 These don't work with wget, but you can download them from a browser. Eventually want to package USB PM tool for distros, but it needs more testing (and the ability for a user to send a report in an automated fashion) before I start pushing it out. Sarah -- 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
