I meant that usbConfig.getNumInterfaces() returns 1 while it should be 16. While there, usbConfig.getMaxPower() gives 250 instead of 500. The version from the last year didn't have these problems.
On the only interface that is found I see all 3 endpoints OK. Queueing will be great to have. I've also seen errors -110, then unplug/plug of cables and rmmod are of no help, reboot is the only way out. I don't know if that's related to queueing though. The easiest way to trigger -110 was by unplugging/plugging back a Cypress HID device (not the one with many configs and interfaces) while making submissions to the pipe. It was also happening without such abuse once in a while but I don't know of another easy way to create it. Sorry for the delay, Boris > > On Mon, 28 Oct 2002, Boris Dainson wrote: > > >Cool, it's finding config 2 properly on this device. It still shows only one > >interface out of 16 though. > > hmm, do you mean 1 of 16 alternate settings or real separate interfaces? > > the SwingUsbView was only displaying real seperate interfaces, I just > added support to show alternate settings to...try it out now. > > >BTW, I've lost hubs and devices while working with the version from the last > >year. It'll be great to know if it's possible to resolve this situation from > >an app (without reboot). > > this is a problem with the Linux UCHI driver(s), both usb-uhci and uhci. > The problem is they don't support control queueing, so if javax.usb talks > to a device (to get strings, for example) at the same time as the kernel > hub daemon (which maintains the USB topology) then the hub daemon may get > "confused" and think a device, or worse an entire hub, has become > unresponsive and it disables that device (or entire hub and subdevices). > Which is of course really bad. > > I finally got tired of it and added control queueing to the uhci driver in > the 2.5.44 kernel. I'm not so sure about the upcoming 2.4.20 kernel, > there's no support there yet, but I (or someone else) may get around to > backporting the queueing support. > > Anyway, as a (hopeful) workaround, I removed all code that causes > connection-time control transfers. However, if any javax.usb drivers > cause bus traffic within a couple seconds (the Linux hotplug code takes > usually 5 seconds and sometimes much, much more) then there may still be > problems. And, if the devices file is used to determine active > configs, the same problem may occur. I changed it to default to set > all configs active (which is fine for all devices except those with > multiple configs). The real solution is getting the 2.4.X uhci driver to > support control queueing. > > And in most cases, I don't think it's possible to resolve from an app. > Best case is rmmod the uhci (or usb-uhci) driver, and modprobe it back up > to re-enumerate the bus. Or, unplug/replug the device(s). > > > -- > Dan Streetman > [EMAIL PROTECTED] > --------------------- > 186,272 miles per second: > It isn't just a good idea, it's the law! > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > javax-usb-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/javax-usb-devel > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ javax-usb-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
