Hi, 2011/1/17 Rémi Denis-Courmont <[email protected]>: > On Monday 17 January 2011 17:09:38 ext Luiz Augusto von Dentz, you wrote: >> > Cable detection is only one aspect of the problem. Something is still >> > required to determine the USB profile, and and initializing the >> > corresponding backend(s). The PC should not 'see' (enumerate) the USB >> > gadget until after the backend(s) is/are ready to handle PC >> > communication. >> >> That sound a bit racy, > > Yes. Blame the USB forum. > > The USB protocol is completely host-centric. Once the USB host sees a gadget, > it is allowed to use it. And if the gadget does not respond fast enough, > depending on the device class, protocol time outs occurs. Then the host will > complain the device is broken. > > Similarly, the gadget should not be exposed to the host until you have > definitely selected the gadget. Otherwise, the host may end up enumerating the > 'wrong' USB profile. At best, it will cause spurious USB device notifications > on > the host (=> bad UX). At worse, it will fail completely. > > > To fix this, USB moded followed this approach (as far as I understand): > - do not draw power from the USB bus by default, > - watch for cable status, > - when cable connection is detected, show the USB profile dialog > (or look up the right profile in the configuration), > - when the USB profile is determined, load the g_* module, > then notify user space back-ends, > - wait for back-ends to signal readiness, > - start drawing power from the bus.
I suppose some parts could actually be done in kernel, a lot of this problems sounds more a limitation of the USB subsystem when acting like a gadget. > -> PC sees the gadget, ready to work. > > (This is probably a bit simplified view.) > > >> it is also strange when compared to Bluetooth >> since the application needs to register itself (both via socket or >> tty) and handle the connections in the same fd, USB seems to do the >> opposite it starts the applications when the cable is plugged and than >> expect them to be able to handle endpoint communication immediately. > > "USB" has no notion of applications. This is an implementation issue for > Linux/MeeGo. Nothing in the USB specifications prevents changing the kernel > USB > gadget framework such you could load multiple g_* modules simultaneously, and > select the active module/the USB profile via, say, sysfs. I actually do like this approach, maybe we should suggest this upstream... > And then, nothing in the USB specifications says that you must deliver SIGHUP > when DTR goes low on a CDC ACM interface or whatever. So you could use a > different mechanism too, such that applications would not need to close and > re- > open their device nodes in that case. > > So all in all, the device nodes could be permanent, and the application > backends could be permanent as well. I am not saying this is necessarily the > right approach. I am just saying that this is a Linux implementation issue. Yep, that is what I was thinking too, I believe this is much simpler to implement and it is a cleaner API to maintain. >> >> but iirc there where some problems to detect cable unplug >> >> since there is no remove event while we keep the tty open and we >> >> cannot depend on HUP because windows/ovi suite is known to generate >> >> them even if the cable is still connected. >> > >> > Normally, HUP should be sent when the PC side application closes the >> > device in PC OS specific manner. For instance, if the application >> > crashes, the gadget side backend needs to be notified that it should >> > restart - *not* that it should exit. This is not specific to Windows; >> > you can trigger it with a Linux PC too. >> >> Well that sounds more like a workaround for application that crashes, >> maybe this is common for USB but I don't think in general treating a >> HUP as a hint to reconnect is a good idea. > > Why? not all! Take the CDC ACM case for instance. The TTY will fire SIGHUP > whenever the USB host lowers DTR (that's a control request for the CDC ACM > interface). Most dial up networking implementations do that to force a > disconnection, and set the modem back to a sane default state. > > That is much less crude and hackish than sending "+++" in band, if you ask me. Well I prefer in band disconnect, maybe because Im used to remove watcher/poll/select when a HUP happens, for instance OBEX do have a disconnect command. Actually for any transport which link loss cannot be immediately detected it is a good practice to disconnect cleanly before shutting down the link, maybe for USB this is not a problem but for Bluetooth it definitely is. >> > Anyway - it is clear that HUP is ambiguous and insufficient, as it does >> > not discriminate physical cable disconnection from logical application >> > disconnection. >> >> Exactly, and by that each application need to know more then just the >> connection itself but the real cable state (from the parent device?), >> now put this in a context where an application/backend is being >> initialized and unplug the cable. It sound pretty racy to me. > > Put like that, it would be racy. For instance, reconnecting the cable before > the applications have picked up the disconnection would fail. > > USB moded was meant to fix exactly that kind of issues... > > I do assume if USB moded was kicked out, something is intended to replace it. This is what Im trying to figure out, maybe we should discuss this in linux-usb mailing list. -- Luiz Augusto von Dentz Computer Engineer _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
