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.<br><br>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.<br>
<br clear="all">Thanks<br><br>Tom<br>
<br><br><div class="gmail_quote">On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic <span dir="ltr"><<a href="mailto:damjan.jov@gmail.com">damjan.jov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Please send the output of "lsusb -v" first so I can see if it's useful.<br>
<br>
Thank you for the offer<br>
<font color="#888888">Damjan<br>
</font><div><div></div><div class="h5"><br>
On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear <<a href="mailto:speeddymon@gmail.com">speeddymon@gmail.com</a>> wrote:<br>
> Now that I think about it, I have a webcam which the last supported windows<br>
> version was XP. I'm not using it for anything since I have another one which<br>
> is supported in 7 and linux, but I don't know if it's picked up in linux<br>
> either. I could send it your way too tho.<br>
><br>
> Thanks<br>
><br>
> Tom<br>
><br>
><br>
> On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear <<a href="mailto:speeddymon@gmail.com">speeddymon@gmail.com</a>> wrote:<br>
>><br>
>> I have a USB pedometer that uploads the data to the internet. I could get<br>
>> another one and the driver software for you to play with. You have to be a<br>
>> registered member for a monthly fee to get one otherwise, but my job<br>
>> sponsors anyone that wants to get/stay in shape that works for them, so<br>
>> getting an extra pedometer is fine by me. I have been hoping for an<br>
>> opportunity to mention that it doesn't work, and this seems like as good as<br>
>> any. :-)<br>
>><br>
>> Thanks<br>
>><br>
>> Tom<br>
>><br>
>><br>
>> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic <<a href="mailto:damjan.jov@gmail.com">damjan.jov@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin <<a href="mailto:eadurbin@gmail.com">eadurbin@gmail.com</a>> wrote:<br>
>>> ><br>
>>> ><br>
>>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic<br>
>>> > <<a href="mailto:damjan.jov@gmail.com">damjan.jov@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> When last I heard from Alexander Morozov (October 2009), he wasn't<br>
>>> >> working on those patches much, and had no interest in sending them to<br>
>>> >> wine-patches.<br>
>>> >><br>
>>> >> I did some work on USB since then, and sent some patches starting from<br>
>>> >> around March 2010 (too many attempts to list, search for them). Most<br>
>>> >> were rejected.<br>
>>> >><br>
>>> >> The USB story goes as follows:<br>
>>> >><br>
>>> >> My libusb patch was rejected IIRC because the libusb situation was<br>
>>> >> unclear. There's the old libusb-0.1 and the new more powerful<br>
>>> >> libusb-1.0. IIRC each *nix hacked up its own specific variation of<br>
>>> >> libusb that had to be detected specifically, and some *nixes didn't<br>
>>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only supports<br>
>>> >> Linux and MacOS when last I checked, and they were doing a Windows<br>
>>> >> port).<br>
>>> >><br>
>>> >> The ntoskrnl that Wine currently emulates is total bogus: one process<br>
>>> >> per driver, drivers all in separate processes from each other. On<br>
>>> >> Windows there's a single address space for all drivers and they can<br>
>>> >> communicate amongst themselves. I don't think inter-driver<br>
>>> >> communication is that crucial initially, but it will be eventually<br>
>>> >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and<br>
>>> >> multi-function USB devices can use a different driver for each<br>
>>> >> interface - these may communicate among themselves with private ioctl<br>
>>> >> requests). The big problem with the multi process situation is<br>
>>> >> hardware sharing: how do you set it up so each driver accesses its own<br>
>>> >> and only its own hardware?<br>
>>> >><br>
>>> >> Drivers either start on system startup (Wine starts those with the<br>
>>> >> first process that starts), or get loaded on-demand as the hardware is<br>
>>> >> plugged in. Most drivers should install themselves to be loaded<br>
>>> >> on-demand. Who loads those and how?<br>
>>> >><br>
>>> >> Windows uses USBHUB.SYS to do device I/O and load drivers on demand.<br>
>>> >> Alexandre didn't want that dll because it exports nothing (all its<br>
>>> >> features are accessible via internal ioctls), and suggested adding the<br>
>>> >> features to USBD.SYS instead, which we already have and which has<br>
>>> >> exports. Now USBD.SYS is linked to by most (but not all) USB drivers<br>
>>> >> so (most of the time) it automatically gets loaded into each one -<br>
>>> >> great right? - but it has no idea which driver it got loaded with, nor<br>
>>> >> a straightforward way to determine which device(s!) that driver wants<br>
>>> >> to drive. Also, since most drivers only load on-demand, the driver<br>
>>> >> will never load, and thus this won't work unless we load those drivers<br>
>>> >> on startup instead. The other approach, which I tried, was to get<br>
>>> >> Wine's mountmgr.sys to detect USB devices using HAL, then pass them to<br>
>>> >> a loaded-on-startup instance of USBHUB.SYS using a Wine-private ioctl,<br>
>>> >> which would detect the driver for the device and launch a new instance<br>
>>> >> of itself that would make a device object and load the driver to<br>
>>> >> attach to it. This was all a bit a hack (USBHUB.SYS uses environment<br>
>>> >> variables to tell the child which device and driver to run) and<br>
>>> >> Alexandre also didn't the the Wine-private ioctls. Alexander Morozov's<br>
>>> >> patch did things the Windows way: all drivers in one ntoskrnl process<br>
>>> >> - this won't work properly in Wine for years, if ever, since ntoskrnl<br>
>>> >> is so incomplete and one bad driver will crash them all. Another<br>
>>> >> possibility could be to keep drivers in separate processes, but allow<br>
>>> >> inter-process communication, but I see serializing IRPs between<br>
>>> >> processes as being complex and very slow.<br>
>>> >><br>
>>> >> Driver installation is also quite a mission. Windows detects that the<br>
>>> >> hardware doesn't have a driver installed, and then generates the<br>
>>> >> device ID and compatible IDs and searches .INF files for one that can<br>
>>> >> support it. Our setupapi needs to be substantially improved to be able<br>
>>> >> to do the same, and some newdev.dll and manual INF parsing work to<br>
>>> >> install the driver may also be necessary, and I can already think of<br>
>>> >> cases where even class installers will be necessary too :-(.<br>
>>> >><br>
>>> >> Wine only sends DeviceIoControl to drivers. For anything non-trivial,<br>
>>> >> other file-related user-space functions (at least ReadFile, WriteFile)<br>
>>> >> need to go to the driver too. The infrastructure for this does not<br>
>>> >> even exist yet, and would probably affects wineserver as well.<br>
>>> >><br>
>>> >> Regression tests for ntosnkrl.exe and kernel drivers don't exist, and<br>
>>> >> are difficult to come up with, since we'd have to compile and load<br>
>>> >> drivers on Windows and run tests that don't crash Windows :-).<br>
>>> >><br>
>>> >> So the architecture for USB support is tricky to say the least. But<br>
>>> >> I'd still like to resume work on my USB patches some time soon, would<br>
>>> >> you like to help?<br>
>>> ><br>
>>> > I'd be willing to help if you want some assistance. I don't know much<br>
>>> > about<br>
>>> > the subject yet, but I'm reading programming the wdm atm.<br>
>>><br>
>>> Firstly I'd like to find a cheap simple USB device that we can<br>
>>> actually get working quickly. Earlier I was experimenting with my<br>
>>> Blackberry driver, but that's not going far quickly, since it's a<br>
>>> multi-protocol device (modem, mass storage, and proprietary protocols,<br>
>>> etc.). I've got a USB scanner that's unsupported by SANE, but that<br>
>>> needs ReadFile/WriteFile which is a lot of work by itself. Same with<br>
>>> USB flash sticks. I can get hold of an iPod but that's probably the<br>
>>> most complex, needing to stack on top of USBSTOR.SYS IIRC. Ironically<br>
>>> drivers for the easy hardware (USB mice) are unnecessary anyway, since<br>
>>> the Linux drivers are good enough, and the Windows drivers probably<br>
>>> need to be driven from user-space by bits Wine doesn't have. Maybe I<br>
>>> should give up and just get something partially working, add the rest<br>
>>> later gradually. Any ideas?<br>
>>><br>
>>> Then it's largely a matter of design. I think Alexandre's idea<br>
>>> (process per driver, host all USB code in USBD.SYS) is good enough<br>
>>> initially.<br>
>>><br>
>>> Essentially the first steps would be:<br>
>>> 1. libusb integration<br>
>>> 2. driver loading hacks<br>
>>> 3. driver -> devices lookup<br>
>>> 4. usb bus enumeration for devices<br>
>>> 5. create pdo and fdo for each device<br>
>>> 6. AddDevice to driver<br>
>>> 7. perform I/O for IRPs coming down from the driver using libusb I/O<br>
>>> functions<br>
>>><br>
>>> That should get a very basic driver (that only uses the control pipe)<br>
>>> working. I'll try to get some of this done later this week/weekend.<br>
>>><br>
>>> Damjan<br>
>>><br>
>>><br>
>><br>
><br>
><br>
</div></div></blockquote></div><br>