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. I guess the main question to the above is "why?" Well as devices are becoming more and more capable they are no longer either individual devices, keyboard/disk/printer/etc. or limited to being accessed as a couple of types, eg. a camera can be a capture device and/or a mass storage device. Buy presenting the device as a hub it would be possible in user-space, both on the host and the device, to allow... (a) a simple consistent interface and run-time selection and set-up of multiple device types. (b) physical/virtual device pass-through. (c) potentially true two way independent simultaneous control of both host controlling device and device controlling host. Practical uses/implications/problems. (a) is obvious and I'm guessing quite easy to implement, a hub is a hub even if virtual. It would reduce the requirement for both a single and multiple type/function gadget interface(s) so all the interfaces are single function interfaces as far as gadget drivers are concerned. For multi-device hardware devices, such as a camera, the specification doesn't change but there is no reason such a device couldn't implement a virtual hub approach. The following is kind of the second part. (b) at present the device types are fairly limited:- Ethernet/ RNDIS/mass storage/serial/gadgetfs. However if a device has other physical/virtual devices, USB keyboard/USB LCD screen/USB touch-screen component/virtual keyboard/etc; it would be useful to allow these devices to be shown and used by the host and/or the gadget either by direct pass-through or an intermediate task. Direct passthough:- To explain direct pass-through I guess I should give an example. I have a beagleboard, connected to the beagleboard is a real USB keyboard and mouse, a virtual on-screen keyboard, an external USB HD, and a 7" touch-screen. Somehow magically this, including battery, is not much bigger than the 7" touch-screen and I can use this set-up to store RAW photographs directly from my DSLR and do limited edits and type notes while out and about and convert from RAW to JPEG. When I get home I plug this into my PC host, at this point the beagleboard and PC negotiate and decide that the keyboards (USB & Virtual) and screens (LCD and touch component) will become direct pass-though devices. The beagleboard then de-allocates these devices from its self and attaches them to the virtual hub. Now while the beagleboard has to do some processing of these devices its not much more than read/store/forward. The PC sees 2 new keyboards, a USB display, and a USB touch-screen component and handles them as if they were directly attached via a standard hub. Intermediate tasks:- At the same time the above was going on the beagleboard also presented an Ethernet gadget, established a network IP, and fired up samba to share the USB HD. Alternatively it set up a USB mass storage device. (c) This part is the hardest to explain, and would possibly require changes to other parts of the kernel/X11/god knows what else... but then again, maybe not! Using my above example I package the whole lot up and call it a Graphical Storage and Editing Tablet, GSET. When the GSET is connected to the PC this time they decide that the LCD and touch-screen component will be shared somehow. Some of the work will be handled by the PC some by the GSET. Double clicking the blank GSET screen opens a file edit dialogue and shows the content of the GSET disk, upon opening a file GIMP bursts into life on the PC and displays the picture on the large display connected to the PC. The GSET also displays just the picture (none of the GIMP menus etc.) scaled down with 4 borders. Touching and scrolling the left border scales the picture displayed on the GSET, top border scales the picture on the PC monitor. Bottom border scrolls the picture on the GSET and PC monitor left/right and likewise right border scrolls the picture up/down. Picture scrolling is proportionate to the relative scaling between the PC and GSET displays. Doing anything inside the borders with the GSET screen acts in the same way a normal graphics tablet does conversing with the PC, which acts and then updates the PC display returns the changed data to the the GSET display which then updates the sub-window within the borders. The corners of the GSET could be programmed to do specific tasks, both in collaboration with the PC or independently just on the GSET depending on what application is running on the PC side. -- 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
