USB Device Support

[Damjan Jovanovic]

When last I heard from Alexander Morozov (October 2009), he wasn't
working on those patches much, and had no interest in sending them to
wine-patches.

I did some work on USB since then, and sent some patches starting from
around March 2010 (too many attempts to list, search for them). Most
were rejected.

The USB story goes as follows:

My libusb patch was rejected IIRC because the libusb situation was
unclear. There's the old libusb-0.1 and the new more powerful
libusb-1.0. IIRC each *nix hacked up its own specific variation of
libusb that had to be detected specifically, and some *nixes didn't
support the libusb-1.0 interface yet (libusb-1.0 itself only supports
Linux and MacOS when last I checked, and they were doing a Windows
port).

The ntoskrnl that Wine currently emulates is total bogus: one process
per driver, drivers all in separate processes from each other. On
Windows there's a single address space for all drivers and they can
communicate amongst themselves. I don't think inter-driver
communication is that crucial initially, but it will be eventually
(eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and
multi-function USB devices can use a different driver for each
interface - these may communicate among themselves with private ioctl
requests). The big problem with the multi process situation is
hardware sharing: how do you set it up so each driver accesses its own
and only its own hardware?

Drivers either start on system startup (Wine starts those with the
first process that starts), or get loaded on-demand as the hardware is
plugged in. Most drivers should install themselves to be loaded
on-demand. Who loads those and how?

Windows uses USBHUB.SYS to do device I/O and load drivers on demand.
Alexandre didn't want that dll because it exports nothing (all its
features are accessible via internal ioctls), and suggested adding the
features to USBD.SYS instead, which we already have and which has
exports. Now USBD.SYS is linked to by most (but not all) USB drivers
so (most of the time) it automatically gets loaded into each one -
great right? - but it has no idea which driver it got loaded with, nor
a straightforward way to determine which device(s!) that driver wants
to drive. Also, since most drivers only load on-demand, the driver
will never load, and thus this won't work unless we load those drivers
on startup instead. The other approach, which I tried, was to get
Wine's mountmgr.sys to detect USB devices using HAL, then pass them to
a loaded-on-startup instance of USBHUB.SYS using a Wine-private ioctl,
which would detect the driver for the device and launch a new instance
of itself that would make a device object and load the driver to
attach to it. This was all a bit a hack (USBHUB.SYS uses environment
variables to tell the child which device and driver to run) and
Alexandre also didn't the the Wine-private ioctls. Alexander Morozov's
patch did things the Windows way: all drivers in one ntoskrnl process
- this won't work properly in Wine for years, if ever, since ntoskrnl
is so incomplete and one bad driver will crash them all. Another
possibility could be to keep drivers in separate processes, but allow
inter-process communication, but I see serializing IRPs between
processes as being complex and very slow.

Driver installation is also quite a mission. Windows detects that the
hardware doesn't have a driver installed, and then generates the
device ID and compatible IDs and searches .INF files for one that can
support it. Our setupapi needs to be substantially improved to be able
to do the same, and some newdev.dll and manual INF parsing work to
install the driver may also be necessary, and I can already think of
cases where even class installers will be necessary too :-(.

Wine only sends DeviceIoControl to drivers. For anything non-trivial,
other file-related user-space functions (at least ReadFile, WriteFile)
need to go to the driver too. The infrastructure for this does not
even exist yet, and would probably affects wineserver as well.

Regression tests for ntosnkrl.exe and kernel drivers don't exist, and
are difficult to come up with, since we'd have to compile and load
drivers on Windows and run tests that don't crash Windows :-).

So the architecture for USB support is tricky to say the least. But
I'd still like to resume work on my USB patches some time soon, would
you like to help?

Damjan Jovanovic

On Tue, Sep 14, 2010 at 4:33 PM, James Mckenzie
<jjmckenzie51 at earthlink.net> wrote:
> Alexander:
>
> Before I go off and try to update your USB device support for the latest Wine release, are you continuing to maintain this code current to the Wine Development and Wine Stable trunks?
>
> Also, the USB Device Support in Wine Wiki page needs an update.  The code at snicky.com is no longer available.
>
> Thank you for your efforts to support USB devices in Wine.
>
> James McKenzie
>
>
>
>