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....@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 <speeddy...@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 <speeddy...@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....@gmail.com > > > >> wrote: > >>> > >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin <eadur...@gmail.com> > wrote: > >>> > > >>> > > >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic > >>> > <damjan....@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 > >>> > >>> > >> > > > > >
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)