USB Device Support

Tom Spear speeddymon at gmail.com
Tue Sep 21 10:04:24 CDT 2010


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
> >>>
> >>>
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100921/0b3fb821/attachment.htm>
-------------- next part --------------
Bus 003 Device 004: ID 1125:2000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x1125 
  idProduct          0x2000 
  bcdDevice            1.06
  iManufacturer           1 SportBrain In
  iProduct                2 SportBrain USB
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          2 SportBrain USB
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               26mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              2 SportBrain USB
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      28
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)


More information about the wine-devel mailing list