[quoted lines by Alan Stern on 2007/06/11 at 10:55 -0400] >Do you really need a reboot, or is it enough to unplug and then replug >the device?
It seems that it's really some kind of timing issue. Unplugging/replugging the device doesn't seem to help, but, after a reboot, the device eventually does become usable but only after a while. I'm assuming now that one of the retries just eventually works for some reason. >It sounds like the device is being suspended, as you surmised. And >apparently it doesn't function properly after being resumed, which >means it isn't fully USB-compliant. Is there some kind of time delay involved in resuming the device that we mightn't be allowing for? >You can prevent the device from being autosuspended by doing: > > echo 0 >/sys/bus/usb/devices/.../power/autosuspend > >(fill in the device ID). Am I correct that thd device id here is the bus number and device number (no leading zeros) separated by a - as taken from the usbfs path being used? >However this would have to be done very quickly following device detection to >prevent an initial autosuspend. Actually, this seems to work. Writing 0 to that file makes it so that either the first or second attempt thereafter does succeed. That's another thing causing me to now wonder if we should be allowing, perhaps, for extra time after the usbfs open resumes the device. If so, is there a way we can tell if the device is currently suspended or not because introducing unrequired delays would introduce unneeded delays into our autodetection loop. By the way: is it the usbfs open or the first write which resumes the device? >(Note that in 2.6.22 the value to write changes from 0 to -1.) Is there a way, other than inspecting the kernel release, to know which value is the one to use? What's the effect of writing -1 with a 2.6.21 kernel? >But it won't prevent all suspends; if somebody puts their system to >sleep using suspend-to-RAM then the braille display device will get >suspended along with everything else. Even if CONFIG_USB_SUSPEND isn't >turned on. That's true as well for systems preceding 2.6.21. I understand. That's why I'm in search of a good way to truly resume the device rather than list it as an exception. >So the best approach might be for brltty to reset the device using a >USBDEVFS_RESET ioctl (or the libusb equivalent, usb_reset) when the >device file is first opened. Or maybe to do this if the device fails >to respond to some standard request when it is first opened. Doing this just after the usbfs open but before any other operation didn't make any difference. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ ------------------------------------------------------------------------- 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-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
