Sadly my knowledge of C was not up to this in the end.
However what I did manage was a little bit more of "if it could it would do it this way" overview.
http://usbip.sourceforge.net/
The documentation (down the page a bit) shows how usb over ip works.
What I would have done is when my device (server) was plugged into the pc the pc would load the usbdriver for my device, this would be exactly the same as the usb-ip VCHI except instead of usb over ip, it would be usb over usb.
1) Where something in my device was connected via usb, it would work exactly as shown in the usb-ip diagram creating a stub driver. eg. a usb keyboard plugged into my device.
2) Where something was not connected via usb, eg. a hard drive or a virtual keyboard on the screen, it would create a _fake_ stub driver of an already known usb device and would then translate the usb requests to the real (hard drive) or virtual (keyboard) device.
For item 2, I'm not sure how much work would be involved as I'm a little unsure how usb works at this point... my guestimate is that its no more than an end to end wrapper over the underlying hardwares native data/control types, the thinking behind this guess is because a usb hard drive can have a different hard drive (size/make) connected and it still works so there must be an abstraction between the usb type/make and the underlying physical hardware type. (a)
eg. diskrequest-seek>wrapped usbSoftwareControl>PhysicalUsb>----wire---->PhysicalUsb>un-rapped usbHardwareControl>diskrequest-seek>physicalHD
If the above is true, then the fake stub would strip away the usb controlling data (request) to get at the raw device command, and then send that command to the devices hardware stack, get the resulting data, wrap it back into usb control data (result) and then send it over the usb.
I did also think about this a little further... when an item of hardware in the server (mydevice) was in passthrough mode it may also be needed exclusively for that device at times. If the mydevice was a notepad with a screen, and a virtual keyboard, there might be times when the keyboard was needed for the notepad itself, say the notepad was running an email client, when a new mail message pops up hitting a special combination of keys on the virtual keyboard would cause the keyboard to no longer send data via the stub driver, the driver would however stay active and connected to the vhci, it would still receive the key presses it would just not send them on... another special combination of keys would then cause the driver to once again send data to the pc.
(a) this abstraction is not however complete, a usb harddrive does not return a controler type (ie sata) it returns a device type (hd) if you plug in a CD drive into a usb harddrive (by opening it and taking out the tiny PCB and connecting that to the cd player + power cord) it does not work as HD commands, not CD commands are sent... that said I see no reason why the writer of the usb driver could not have written a slightly more abstract driver that would first query the device attached to the usb, then initiate the correct device in the usb/device interface such as "this is a hd" or "this is a XX type cd/dvd drive"
