On Sun, 17 Jun 2007, Dave Mielke wrote: > [quoted lines by Alan Stern on 2007/06/17 at 10:48 -0400] > > >> >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. > >> > >> Is it guaranteed that two busses can't have a device with the same number. > >> In > >> other words, is the following impossibble? > >> > >> /proc/bus/usb/001/001 > >> /proc/bus/usb/002/001 > > > >It isn't impossible. In fact it happens all the time. > > Maybe I missed something then. .../devnum confirms that the device number is > right, but how does one additionally confirm that the bus number is correct?
Starting in 2.6.22 there's a .../busnum file containing the bus number. However you really don't need it, because the first part of the sysfs device ID (the portion preceding the '-') is the bus number. > It turns out that a delay of 550 (ms) starts to work, albeit intermittently, > and a delay of 700 seems to work all the time. That's a bit long for the > autodetect loop, but it's certainly the cleanest approach. I agree. Especially since you never know when somebody might have had their entire system, including the Braille device, suspended. 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. > 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? > 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. 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
