2013/10/29 Johannes Stezenbach <j...@sig21.net>: > 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. >
I am affraid you are confusing the relative order in which the interface descriptor appears inside a configuration descriptor (which is irrelevant to USB spec), and the interface number, which is actually used for USB, say, for interface claiming. They are not necessarily equal... > >> >> > 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. > This probably is device specific, that's the reason is real hard to have generic sample code that will work for you, and that's because I chose to post minimum code snippets in the tutorial. > 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. > Maybe it is just a debug info without real meaning... -- Best Regards, Wander Lairson Costa ------------------------------------------------------------------------------ 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
