Re: USB-OTG "virtual hub" some help/ideas/comments please.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2010-04-20 at 15:08 -0400, Alan Stern wrote:
> On Tue, 20 Apr 2010, Greg KH wrote:
> 
> > On Tue, Apr 20, 2010 at 06:09:05PM +0100, Jonathan Wilson wrote:
> > > I've looked around the net and not found anything, although that might
> > > be because I'm using the wrong search words, for something similar to
> > > the following.
> > > 
> > > What I'm looking for is, kind of, in two parts.
> > > 
> > > One is some form of USB-OTG gadget driver virtual hub, so that a
> > > peripheral device connected to a PC would fake it's self into appearing
> > > as a standard physical hub. Obviously such a hub would either have to
> > > fake its device id's/types/sub/etc. to pretend to be an existing hub, or
> > > would require a new id, etc; properly registered.
> > 
> > The main problem is that the majority of what a hub does needs to be in
> > hardware, due to the speed issues that are required here.  not to
> > mention the complexities of properly handling the USB protocol (USB 2.0
> > hubs with USB 1.1 devices plugged into them are nasty things, it took a
> > long time to get that hardware right...)
> > 
> > So just by virtue of the electronics involved, this might be a very
> > impossible wish, sorry.
> 
> That's right.
> 
> Even at the most superficial level there's a fundamental problem: The
> USB-OTG device controller hardware will respond only to packets sent to
> its own address.  But if it had virtual devices "plugged in" (in the
> form of gadget drivers), then it would also have to respond to packets
> sent to these devices' addresses.  Clearly that cannot be made to work.
> 
> Alan Stern
> 
Most helpful, thank you. Yours and Gregs posts pointed me to look at the
protocol for device addressing (as you may have guessed I'm not a C nor
PC programmer coming from an AS/400 application programmer background)
and now I can see the problem :-( The OTG controller having its own
address and USB2 being a global broadcast protocol. Hence the need for
the composite device.

Thinking abstractly... 

It is now possible to carry USB over TCP/IP so I'm guessing it would be
possible to hash my idea by making a USB TCP/IP connection and then map
back the physical and virtual USB devices over TCP/IP back to the host.

Or write a host and gadget driver that would wrap USB over USB so that
the outer packet would go to the OTG controller and the inner packet(s)
would go to sub-devices, but this is possibly a bigger kludge than using
USB over TCP/IP. Infact thinking about it further it would break USB
host as each end device transmission would need to be checked to see if
it should be transmitted normally or be wrapped up and sent to the OTG
controller.

Back to the drawing board :-/


--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux