Hello everyone. I'm writing a KMDF bus driver which aims to emulate various kinds of devices. I'm learning as I go, so far I've managed to emulate HID devices successfully. For the purposes of the question I will focus on a different area, namely USB device emulation.
I've learnt there are a few ways to approach this and I'd like to know what are the advantages/disadvantages of each one.
The highest-level approach is the "UDE" framework from Microsoft. It attempts to hide most of the complexity. In exchange we are offered some bugs such as this one: Isochronous endpoints MSFT UDE
One can emulate a USB host controller together with the root hub. This approach is used by GitHub - OpenXT/xc-vusb . It's quite a lot of code.
UDE has poor documentation and no official example code (that would actually compile) but despite that it looks like the best option so far, assuming that the bugs can be worked around. It forces a specific structure (such as setting up separate WDF queue for each endpoint, instead of receiving a simple URB stream), which may be useful for emulating one specific USB device, but is not very convenient when one wishes to emulate arbitrary devices and just stream the URBs back to a userspace application.
One layer below is UCX, a framework designed for implementing USB controller drivers. In terms of devices and endpoints it seems to follow the same structure as UCX, so effectively it offers increased complexity for little gain. I guess that the "query bus time" issue might not be present here though.
The xc-vusb project represents another step up in complexity. It looks as if it's implementing an USB controller without any specific-purpose framework. It's complex and tedious, but on the upside - the most flexible approach.
Finally, the ViGEmBus approach takes a shortcut across the whole stack. On the surface it seems to be one of the simplest options (at least in terms of code size).
Unfortunately, in order to be compatible with the rest of the OS, the driver needs to replicate whatever usbhub & usbport drivers are doing. Amongst other things, this means setting hardware ids & compatible ids exactly as the os-provided drivers would. This seems manageable when emulating specific USB devices (as ViGEmBus does), but increasingly complex & brittle when attempting to emulate arbitrary devices.
As the author of xc-vusb I’m just happy anyone is considering using it. It was pre-usb3 so there is that. It is complicated because the usb architecture is complicated and there is no getting around that. Had there been a msft alternative at the time I would have at least experimented with that first.
Hi, this chat looks like something I'm after, so ill ask here...
Is it possible to create a usb that will make my computer think that its a plotter and receive the print file so i can open it in say illustrator ?
It is considered impolite here to hijack another thread for your own question. You should ask a new question.
What application is doing the printing here? Most drawing applications have methods of exporting directly to AI or SVG files. Alternatively, there are apps that can convert from almost any drawing format you have to another drawing format.
Writing a fake printer/plotter driver is a lot of work, and you would still have to figure out how to write the result in a known format.