USB Device Support

[Tom Spear]

On Wed, Sep 22, 2010 at 2:26 AM, Damjan Jovanovic <damjan.jov at gmail.com>wrote:

> On Wed, Sep 22, 2010 at 1:52 AM, Tom Spear <speeddymon at gmail.com> wrote:
> > 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
> >
>
> It could be using the generic human interface device driver provided
> by Microsoft, the older user-space USB IOCTLs, or the Windows XP and
> later UMDF (user mode driver framework).
>
> A +file trace on Wine would tell us what it's doing.
>
> Thanks
> Damjan
>

I will try that when I get off of work. I'm definitely curious to see how it
is trying to read the serial number and other data from the pedometer
itself. BTW, I have SSH setup already, as I remote in from work to monitor
some things, but I prefer to use public keys, so if you don't already have
one generated, you'll need one when it is time for you to login and tinker.
;-)

Results in the morning.

Thanks

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