Re: USB Device Support

[Tom Spear]

Now that I think about it, I have a webcam which the last supported windows
version was XP. I'm not using it for anything since I have another one which
is supported in 7 and linux, but I don't know if it's picked up in linux
either. I could send it your way too tho.

Thanks

Tom

On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear  wrote:
> I have a USB pedometer that uploads the data to the internet. I could get
> another one and the driver software for you to play with. You have to be a
> registered member for a monthly fee to get one otherwise, but my job
> sponsors anyone that wants to get/stay in shape that works for them, so
> getting an extra pedometer is fine by me. I have been hoping for an
> opportunity to mention that it doesn't work, and this seems like as good as
> any. :-)
>
> Thanks
>
> Tom
>
> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic wrote:
> > On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin  wrote:
> > > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic <
> >
> > [e-mail]>
> > > wrote:
> > > > 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?
> > >
> > > I'd be willing to help if you want some assistance. I don't know much
> >
> > about
> > > the subject yet, but I'm reading  programming the wdm atm.
> >
> > Firstly I'd like to find a cheap simple USB device that we can
> > actually get working quickly. Earlier I was experimenting with my
> > Blackberry driver, but that's not going far quickly, since it's a
> > multi-protocol device (modem, mass storage, and proprietary protocols,
> > etc.). I've got a USB scanner that's unsupported by SANE, but that
> > needs ReadFile/WriteFile which is a lot of work by itself. Same with
> > USB flash sticks. I can get hold of an iPod but that's probably the
> > most complex, needing to stack on top of USBSTOR.SYS IIRC. Ironically
> > drivers for the easy hardware (USB mice) are unnecessary anyway, since
> > the Linux drivers are good enough, and the Windows drivers probably
> > need to be driven from user-space by bits Wine doesn't have. Maybe I
> > should give up and just get something partially working, add the rest
> > later gradually. Any ideas?
> >
> > Then it's largely a matter of design. I think Alexandre's idea
> > (process per driver, host all USB code in USBD.SYS) is good enough
> > initially.
> >
> > Essentially the first steps would be:
> > - libusb integration
> > - driver loading hacks
> > - driver -> devices lookup
> > - usb bus enumeration for devices
> > - create pdo and fdo for each device
> > - AddDevice to driver
> > - perform I/O for IRPs coming down from the driver using libusb I/O
> >
> > functions
> >
> > That should get a very basic driver (that only uses the control pipe)
> > working. I'll try to get some of this done later this week/weekend.
> >
> > Damjan