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. :-)<br>
<br clear="all">Thanks<br><br>Tom<br>
<br><br><div class="gmail_quote">On Tue, Sep 21, 2010 at 5:03 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;">
On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin <<a href="mailto:eadurbin@gmail.com">eadurbin@gmail.com</a>> wrote:<br>
<div><div></div><div class="h5">><br>
><br>
> On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic <<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>
</div></div>> I'd be willing to help if you want some assistance. I don't know much 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 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>
<font color="#888888"><br>
Damjan<br>
<br>
<br>
</font></blockquote></div><br>