USB Device Support

[Tom Spear]

On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic <damjan.jov at gmail.com>wrote:

> On Tue, Sep 21, 2010 at 8:07 PM, Tom Spear <speeddymon at gmail.com> wrote:
> > On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic <damjan.jov at gmail.com
> >
> > wrote:
> >>
> >> On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear <speeddymon at gmail.com>
> wrote:
> >> > Attached is the lsusb -v output, trimmed to only include the
> pedometer's
> >> > info. I have many USB devices, so I didn't want to leave you to sort
> >> > through
> >> > a bunch of useless info.
> >> >
> >> > I don't have the webcam with me at the moment, but I will see if I can
> >> > find
> >> > it when I am at home soon.
> >> >
> >> > Thanks
> >> >
> >> > Tom
> >> >
> >> >
> >> > On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic <
> damjan.jov at gmail.com>
> >> > wrote:
> >> >>
> >> >> Please send the output of "lsusb -v" first so I can see if it's
> useful.
> >> >>
> >> >> Thank you for the offer
> >> >> Damjan
> >> >>
> >> >> On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear <speeddymon at gmail.com>
> >> >> wrote:
> >> >> > 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 <speeddymon at gmail.com>
> >> >> > 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
> >> >> >> <damjan.jov at gmail.com>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin <eadurbin at gmail.com
> >
> >> >> >>> wrote:
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
> >> >> >>> > <damjan.jov at gmail.com>
> >> >> >>> > 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:
> >> >> >>> 1. libusb integration
> >> >> >>> 2. driver loading hacks
> >> >> >>> 3. driver -> devices lookup
> >> >> >>> 4. usb bus enumeration for devices
> >> >> >>> 5. create pdo and fdo for each device
> >> >> >>> 6. AddDevice to driver
> >> >> >>> 7. 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
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >
> >> >
> >>
> >> It's a human interface device, 1 control pipe and 1 interrupt pipe.
> >> Looks pretty simple. You could also use "winedump -j import" on the
> >> driver to see if it has any dependencies.
> >>
> >> I'll get working on the basics of USB first. If the device doesn't
> >> work on your tests after that, SSH access might be quicker and easier
> >> than intercontinental shipping.
> >>
> >> Thank you
> >> Damjan
> >
> > By driver, do you mean the wine-loaded driver, or whatever kernel module
> > loads in linux?
> >
> >
> > Thanks
> >
> > Tom
> >
> >
>
> The .sys file(s) used on Windows.
>
> Damjan
>


Looking at device manager in windows 7, I see the device, but when I try to
look at driver details, it says no driver files are required or have been
loaded for this device. It is actively used, however. I'm thinking the
software to upload the data from the device interfaces with the device
directly, based on that. I also checked a clean wine drive c with just the
software for this pedometer installed, and didn't see anything that appeared
to have been added, driver-wise, by the installer. However, the software
cannot read the serial number of the device under wine, whereas it can under
Windows.

Thanks

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100921/e26f96f3/attachment-0001.htm>