On Sat, 16 Jun 2007, Dave Mielke wrote: > [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.
What about unplugging the device, turning its power off, then turning its power on and replugging it? For that matter, have you ever tried running brltty immediately after turning the device on? Perhaps the device needs time to "warm up". > >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? Not at the USB level, but perhaps on a different level. > >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? No. This is sysfs; it's not the same as usbfs. You have to look at the files (symbolic links, actually) in the /sys/bus/usb/devices directory and determine which one corresponds to the device in question. The format is: bus number, then '-', then port number (with an additional port number separated by '.' for each USB hub the device is behind). You can tell whether you have the right entry by reading /sys/bus/usb/devices/.../devnum, which contains the usbfs device number without leading zeros. > >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. You can tell whether the device is suspended by reading /sys/bus/usb/devices/.../power/state. The file will contain 0 if the device is running and a positive number if the device is suspended. Note however that this will change, perhaps in the 2.6.23 time frame. For 2.6.21 and 2.6.22 you can rely on it. > By the way: is it the usbfs open or the first write which resumes the device? The open. The resume should be complete by the time open() returns. However the device itself might have additional delay requirements. That is, even though its USB interface will be working okay, the rest of the device might need extra time to warm up somehow. > >(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? The write will fail. > >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. Well, you can try adding a time delay just after the usbfs open. It might help. You'll have to experiment with different delay lengths. Perhaps a few seconds... Alan Stern ------------------------------------------------------------------------- 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
