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. -> 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. 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. > >> 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. > > 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. -- Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
