On Tue, Oct 29, 2013 at 02:58:45PM -0200, Wander Lairson Costa wrote: > 2013/10/29 Johannes Stezenbach <j...@sig21.net>: > > On Tue, Oct 29, 2013 at 12:16:51PM -0200, Wander Lairson Costa wrote: > >> 2013/10/29 Johannes Stezenbach <j...@sig21.net>: > >> > > >> > One remark: The "Let's get it started" example in > >> > docs/tutorial.rst looks confusing, why does it do this: > >> > > >> > cfg = dev.get_active_configuration() > >> > interface_number = cfg[(0,0)].bInterfaceNumber > >> > alternate_setting = usb.control.get_interface(dev, interface_number) > >> > intf = usb.util.find_descriptor( > >> > cfg, bInterfaceNumber = interface_number, > >> > bAlternateSetting = alternate_setting > >> > ) > >> > > >> > instead of just this:? > >> > > >> > intf = cfg[(0,0)] > >> > > >> > >> The code above finds the interface by its interface number, not its > >> index inside the configuration (they are not necessarily the same > >> thing). > > > > Well, I guess the intention is to show how to look up interface > > by bInterfaceNumber, but if you take cfg[(0,0)].bInterfaceNumber > > and look it up then you end with cfg[(0,0)], right? > > What if cfg[0,0].bInterfaceNumber == 2?
We're running in cirecles... maybe I don't understand what the (0,0) index in cfg[(0,0)] means? My assumption is it means the first Interface Descriptor as listed in lsusb -v output. And if the first descriptor has bInterfaceNumber==2 and you look it up with usb.util.find_descriptor() you would get the same first descriptor. > >> > Also, the code lacks an > >> > > >> > intf.set_altsetting() > >> > > >> > >> set_altsetting is only needed by device with alternate settings. > >> > >> > otherwise the EPs are not reset which might lead to errors > >> > (e.g. STALL is not cleaared from previous use), and Linux complains: > >> > > >> > >> Stalled endpoints are not something expected in normal cases. > > > > set_altsetting() is always required before using an interface since it > > resets it into a known state. I mean the tutorial should just work > > and not cause new users to wonder if pyusb is broken... > > > > IIRC, according to USB spec, a device that receives a SET_INTERFACE request > and > does not have additional alternate settings is allowed to return an error. Hm, that's true. I was testing with a Linux based device and gadget g_zero, and the EPIPE error stuck unless I added either intf.set_altsetting() or explicit CLEAR_FEATURE(ENDPOINT_STALL). I remember having read both SET_INTERFACE and SET_CONFIGURATION should reset the endpoint state including data toggles and any device FIFOs, but I'm not sure where I read it. Might have been Cypress FX2 documentation. Now that I think about it the dev.set_configuration() did not seem to have the desired effect. I'll test again tomorrow. > >> > [2249737.372143] usb 1-1.1: usbfs: process 32478 (python) did not claim > >> > interface 0 before use > >> > > >> > >> Interface claiming, in another hand, is handled internally by PyUSB, > >> this might be a bug. > > > > usb.control.get_interface() does not claim the interface. > > > > Ah, no because control requests against endpoint 0 does not need > interface claiming. So I wonder what cause the kernel to complain. Thanks, Johannes ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
