Hi<br><br>There&#39;s essentially 2 ways USB could work in Wine[1]:<br><br>1. Process per driver, but special-case loading and initializing USBD.SYS<br>Like my previous patchset:<br><a href="http://www.winehq.org/pipermail/wine-patches/2010-November/095883.html">http://www.winehq.org/pipermail/wine-patches/2010-November/095883.html</a><br>
<a href="http://www.winehq.org/pipermail/wine-patches/2010-November/095884.html">http://www.winehq.org/pipermail/wine-patches/2010-November/095884.html</a><br><br>2. Dedicated process for USB, in which USBD.SYS loads first, and it loads USB device drivers (possibly &gt; 1) into the same process as the need arises.<br>
<br>What&#39;s the right way? Which approach is going to get my patches accepted?<br><br>Thank you<br>Damjan<br><br>[1] Because the steps are as follows:<br>1. USB device is plugged in<br>2. USB hub driver looks up the driver based on the device class/vendor/product IDs<br>
3. The device driver gets loaded and DriverEntry() gets called on it<br>4. AddDevice() gets called on the driver, specifying the device<br>5. Only then, the driver calls things lower in the stack, to do USB I/O<br><br>The driver needn&#39;t load any other driver in its DLL import table, and even if it did, drivers loaded through the import table don&#39;t have their DriverEntry() called, so they cannot do anything on load. Even if we rely on most USB drivers loading USBD.SYS, USBD.SYS needs to do steps 1-4 first, but it wouldn&#39;t have control passed to it until step 5, hence it can&#39;t ever do anything. The only way out is one of the following:<br>
1. Process-per-driver, but when a driver loads USBD.SYS, USBD.SYS is special-cased by winedevice, ie. it has a special export called on it at load which specifies the other driver and gives it a chance to create a separate thread for steps 1-4.<br>
2. Dedicated process for USB, in which USBD.SYS loads first, and it loads USB device drivers (possibly &gt; 1) into the same process as the need arises.<br><br>