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? > > A lot of work :) > Heh! Ok, as a non C-programmer, I'm looking for the easiest way, then :-D > > I assume there is a small kernel portion that simply relays data to user space, > > and a user space component that processes that data and replies appropriately? > > The files Documentation/usb/gadget* should give you an idea of what is > needed here. But first, I suggest you read up on how USB works, it's a > lot more complex than I think you realize it is... I'm sure it is more complex that I realise, which is why I'm asking questions first. To explain what I am trying to achieve, and possibly the way in which I can go about it, to my understanding: 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. 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. 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. 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. > > good luck, > > greg k-h Thanks for your time. I'm off to go read USB specs, and gadget documentation! :-D Rogan -- 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
