On Sun, 17 Jun 2007, Dave Mielke wrote: > 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.
Can you try all three possibilities, and if all of them fail, wait 100 ms and try again, up to 10 times? > >> 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. I'm not sure what you're asking. Do you want a usbfs interface which provides the same capability as the sysfs interface? I doubt that the USB maintainer would accept it. Note that you don't actually need to do any searching to find the correct sysfs directory. If you look in /sys/class/usb_device you'll find a bunch of subdirectories with names like "usbdev1.2". Here the first number is the bus number and the second is the usbfs device number, so you can go directly to the one you want. In that directory is a symbolic link named "device" which points to the actual sysfs device directory. As a complete example, the usbfs path /proc/bus/usb/002/003 corresponds to the sysfs path /sys/class/usb_device/usbdev2.3/device. So I don't see anything wrong with simply using the sysfs approach. 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
