Thanks for the pointers, Chris! I'll check them all out. It sounds like the USBProxy is going to be the way to go. Rogan On Wed, Dec 02, 2015 at 09:10:10AM -0500, Chris McClimans wrote: > On Wed, Dec 2, 2015 at 7:29 AM, Rogan Dawes <rogan@xxxxxxxxxxxx> wrote: > > On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote: > >> On Wed, Dec 02, 2015 at 01:02:28AM +0000, Rogan Dawes wrote: > >> > Thanks Greg. > >> > > >> > At a high level, what is needed to implement a new type of USB device gadget, > >> > such as a display link device? > > > As mentioned originally, I'm trying to come up with an IP KVM, as inexpensively as possible. Realising that the approach that I am following will not allow me to interact with any layers prior to a successfully booted operating system, what I am hoping to do is, at a minimum, be able to observe the DisplayLink traffic flowing from an external computer (i.e. not a VM) over the USB. > > > As I understand it, I have a couple of options of achieving this: > > > > 1) Have Linux operate as a general purpose hub, and simply plug in a real displaylink adapter to the host ports, and observe the data flowing from one to the other. At least I don't have to worry about actually convincing upstream that I *am* a DisplayLink device. At this point, I can hopefully decode the data to reconstruct the framebuffer, and make it available via e.g. VNC. This seems to be a difficult option, as you have indicated. > > Linux has some built in gadget functions here: > https://github.com/torvalds/linux/tree/master/drivers/usb/gadget/function > but I haven't seen much discussion about creating a f_hub. > > > 2) Have Linux operate as some sort of proxy, in a special case of 1). No need to make it general purpose, so long as I can make it work for the DisplayLink adapter I have, I should be good. This may or may not be easier than 1). Again, with access to the data, I can reconstruct the framebuffer. > > Might look at using a BeagleBone black with > https://github.com/dominicgs/USBProxy as a mitm to observe the traffic. > > > 3) Making use of the Linux driver code already existing for the DisplayLink family, write a gadget driver to act as a DisplayLink device. Using a Windows VM and usbsnoop may make this easier during development. This is obviously the best case, but probably a lot more work than either 1 or 2. > > Yea, I'd shoot for USBProxy, Dominic provides a in image for flashing > the BeagleBone to do use it as a proxy for sniffing. > > > FWIW, while I'm OK with the result not being acceptable by kernel standards, I do plan to make the code freely available to anyone who would like to build on it. > > Another project that might be interesting for you to look at is > https://github.com/pelya/android-keyboard-gadget , @pelya's approach > is to use the camera on the phone, point it at the screen and show up > as a keyboard/mouse gadget to the PC then export the KVM as a VNC > server. > > I'm working on something similar but I want to support exporting USB > devices as their bluetooth countparts and visa versa. Also looking > into adding something similar to DriveDroid > http://softwarebakery.com/projects/drivedroid to dynamically export > installation media via mass_storage and network etc... > https://github.com/ii/iikeyboard/wiki -- 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
