On Mon, Jun 22, 2020, at 11:41 AM, Alan Stern wrote: > On Mon, Jun 22, 2020 at 10:41:14AM -0500, Sid Spry wrote: > > On Mon, Jun 22, 2020, at 9:02 AM, Alan Stern wrote: > > > On Sun, Jun 21, 2020 at 09:25:53PM -0500, Sid Spry wrote: > > > > I now must ask the list: What is the relation of the isochronous endpoint setup > > > > to the allocated bandwidth on the bus? > > > > > > Bandwidth allocation is determined by the host controller driver, or in > > > the case of xHCI, hardware. Therefore it will vary with different drivers > > > or controllers. > > > > > > > Ok, variation I expected. Sadly it seems like I am not made aware of which > > interface alternate setting is chosen. > > > > See: https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/ > > function/f_fs.c#L3265. > > > > The ctrlrequest struct (https://elixir.bootlin.com/linux/latest/source/include > > /uapi/linux/usb/ch9.h#L213) is only sent for SETUP events. Of which I have > > yet to triggered. > > Like I said before, you'll need to ask someone who knows more about > FunctionFS. > This is a mailing list, I am not only expecting you to reply. > > > > libusb seems to encounter an error: > > > > > > > > (pyusb error output) > > > > ``` > > > > >>> import usb > > > > >>> ds = [d for d in usb.core.find(find_all=True, idVendor=0x1d6b, idProduct=0x0104)] > > > > >>> d = ds[0] > > > > >>> d.set_interface_altsetting(interface=1, alternate_setting=1) > > > > Traceback (most recent call last): > > > > File "<stdin>", line 1, in <module> > > > > File "/usr/lib/python3.7/site-packages/usb/core.py", line 902, in set_interface_altsetting > > > > self._ctx.managed_set_interface(self, interface, alternate_setting) > > > > File "/usr/lib/python3.7/site-packages/usb/core.py", line 102, in wrapper > > > > return f(self, *args, **kwargs) > > > > File "/usr/lib/python3.7/site-packages/usb/core.py", line 204, in managed_set_interface > > > > self.backend.set_interface_altsetting(self.handle, i.bInterfaceNumber, alt) > > > > File "/usr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 807, in set_interface_altsetting > > > > altsetting)) > > > > File "/usr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 595, in _check > > > > raise USBError(_strerror(ret), ret, _libusb_errno[ret]) > > > > usb.core.USBError: [Errno None] Other error > > > > ``` > > > > > > > > (libusb error from C code) > > > > ``` > > > > libusb: error [op_set_interface] setintf failed error -1 errno 32 > > > > ``` > > > > > > Error 32 means that the device returned a STALL status when it received > > > the Set-Interface request. The code responsible for this error response > > > might be in FunctionFS or in your driver. > > > > > > > I see the set-interface request in my code as a read/write error on the endpoints > > (errno 11: resource temporarily unavailable) and an enable event. Otherwise > > most things "just happen." > > > > I've had issues reusing endpoint numbers like you are supposed to. Either the > > descriptors aren't accepted or more commonly the UDC won't bind. E.g. I have > > to give interface 0 eps 1, 2 and interface 1 eps 3, 4. The numbering is preserved > > on the host, kind of. Eps are compacted into their numbering based on direction. > > So you see interface 0 with eps 0x81 and 0x01, and interface 1 with eps 0x82 > > and 0x02. > > That's exactly how it's supposed to work. Don't mix up endpoint _numbers_ > with endpoint _addresses_; they aren't the same thing. Read through the > USB-2.0 specification for more information. > > Also don't forget that two interfaces in the same configuration are not > allowed to share an endpoint (other than endpoint 0, which doesn't really > belong to any interface). > > > This isn't causing me problems per se but does seem improper. > > Why? > Ah, yes, I was mixing up numbers/addresses. Strange as the only useful number to me seems to be the address. > > I'll look through the functionfs code when I have some time. The user mode > > does not seem to be passed much information. > > If you think this is a weakness of FunctionFS and it needs to be fixed, > report it to the FunctionFS maintainers. See the MAINTAINERS file in the > top-level directory of the kernel source code. > > > > > But, if interface 1 alternate setting 0 is dropped, and interface 1 alternate > > > > setting 1 is kept, both invocations work and my C code spits out data very > > > > fast, although I must inspect it further as I seem to be duplicating data in my > > > > reads. > > > > > > If you drop altsetting 0 then you're probably not issuing a Set-Interface > > > request. That would explain why you don't get a failure. > > > > > > If you like, you can try issuing a Set-Interface(0) request (even though > > > it's redundant) just to see if it fails. > > > > > > > Ah, yes, I had done set-interface(0 [, 0]). set-interface(1, 0) also works. It is just > > set-interface(1, 1) that is nonfunctional when an alternate mode 0 is provided. > > Okay. Maybe the problem occurs in the code that enables the endpoints for > altsetting 1. > I do appreciate the help, I'll report to the maintainers later. I'll have to table it for now. As it is I'm able to send reliably on each frame so I'm happy.
