On Fri, 9 Apr 2010, Hendrik Sattler wrote: > Am Freitag 09 April 2010 16:52:12 schrieb Alan Stern: > > On Fri, 9 Apr 2010, Hendrik Sattler wrote: > > > I found some additional problems with f_obex: > > > 1. > > > After the client disconnects, a select() call with one FD checking for > > > input data wil always return immediately but read() return 0. I fixed > > > this by closing the device and re-opening. tcflush() doesn't help. > > > > Why is that a problem? Isn't it supposed to work that way? > > I certainly didn't expect it on the gadget (server) side, normal on the host > (client) side. Serial connections are symmetrical, so the same behavior should pertain to both ends of the connection, right? > There's already SIGHUP when the cable is disconnected which is only useful to > reset the internal state of the obex application. I have not so much knowledge > about USB but on the server application side, it's a sudden strange behaviour > of select(), as it signals that there is data to read when there's none. Actually it signals that a read will return immediately, as opposed to blocking. So it isn't sudden strange behavior. > BTW: Is there a way to have enough endpoints to that "modprobe g_serial > use_acm=1 use_obex=1" produces a result that makes ACM and OBEX available? > Currently, I can choose one or the other, not both. Dummy-hcd is flexible; you can get any number of endpoints you want (up to the maximum), with various restrictions on their use, just by editing the ep_name[] array near the start of the source file. For example, you could add ep-g, ep-h, ..., ep-z and remove all the numbered endpoints; that would give you 26 configurable endpoints. I trust that would be enough. :-) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
