[quoted lines by Alan Stern on 2007/06/17 at 16:30 -0400] >Ideally you'd like to find a way to tell when that delay is needed and >when it isn't, or better yet, when the device has fully recovered. >Maybe some test command that won't succeed until the device is ready to >operate, which you could keep retrying at 100-ms intervals.
One of the complications with this particular model is that it supports three modes of operation, i.e. it supports it's own vendour's protocol and is also able to emulate the protocols of two other vendours. What brltty needs to do, therefore, is to try all three until it gets a response. We can be sure that it's the right device based on the USB product/vendour ids, but we'll still need to wait out the delay on the first protocol probe if the device is alive and well but has been set to respond to one of the other protocols. I don't see an easy way to avoid that delay. >> Another thing, though, is that suspending this particular device has an >> undesirable side-effect, i.e. it puts the device into its internal menu mode. > >Can your program tell whether the device is in that mode and switch it >back out? What if the device just happens to be in the internal menu >mode anyway when brltty starts up because of something the user did >previously -- isn't the program able to cope with that? Yes. The "problem" is that it's undesirable to the user to have the device revert to its internal menu mode rather than have a message on his display indicating that brltty closed the device so that he knows what happened. A user can clearly "live with it" that way, but we try to be as nice to them as we can. >> Would you consider adding a way, perhaps an ioctl, to tell an open usbfs >> device >> that it's not to suspend when closed? It'd only need to be a temporary state, >> i.e. it'd just apply to the close of the currently open file descriptor. I >> believe this'd help to resolve both problems. > >There already is such a way, namely writing 0 (or -1) to the >.../autosuspend file. It's not temporary, but you can always revert it >again by writing the former value back to the file. Now that I know how to accurately find the right sysfs device, yes, we can do it this way. The feature, though, might ultimately be generally useful. Were it available, I'd sure prefer to use it. -- 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
