On Wed, Dec 2, 2015 at 7:29 AM, Rogan Dawes <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
