<div class="gmail_quote">On Tue, Sep 21, 2010 at 11:04 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;">
<div><div></div><div class="h5">On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear <<a href="mailto:speeddymon@gmail.com">speeddymon@gmail.com</a>> wrote:<br>
> Attached is the lsusb -v output, trimmed to only include the pedometer's<br>
> info. I have many USB devices, so I didn't want to leave you to sort through<br>
> 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<br>
> it when I am at home soon.<br>
><br>
> Thanks<br>
><br>
> Tom<br>
><br>
><br>
> On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic <<a href="mailto:damjan.jov@gmail.com">damjan.jov@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Please send the output of "lsusb -v" first so I can see if it's useful.<br>
>><br>
>> Thank you for the offer<br>
>> Damjan<br>
>><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<br>
>> > windows<br>
>> > version was XP. I'm not using it for anything since I have another one<br>
>> > 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<br>
>> >> get<br>
>> >> another one and the driver software for you to play with. You have to<br>
>> >> 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<br>
>> >> good as<br>
>> >> any. :-)<br>
>> >><br>
>> >> Thanks<br>
>> >><br>
>> >> Tom<br>
>> >><br>
>> >><br>
>> >> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic<br>
>> >> <<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>><br>
>> >>> 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<br>
>> >>> >> to<br>
>> >>> >> wine-patches.<br>
>> >>> >><br>
>> >>> >> I did some work on USB since then, and sent some patches starting<br>
>> >>> >> from<br>
>> >>> >> around March 2010 (too many attempts to list, search for them).<br>
>> >>> >> 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<br>
>> >>> >> 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<br>
>> >>> >> 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,<br>
>> >>> >> and<br>
>> >>> >> multi-function USB devices can use a different driver for each<br>
>> >>> >> interface - these may communicate among themselves with private<br>
>> >>> >> 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<br>
>> >>> >> 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<br>
>> >>> >> 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<br>
>> >>> >> demand.<br>
>> >>> >> Alexandre didn't want that dll because it exports nothing (all its<br>
>> >>> >> features are accessible via internal ioctls), and suggested adding<br>
>> >>> >> 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<br>
>> >>> >> 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,<br>
>> >>> >> nor<br>
>> >>> >> a straightforward way to determine which device(s!) that driver<br>
>> >>> >> 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<br>
>> >>> >> 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<br>
>> >>> >> to<br>
>> >>> >> a loaded-on-startup instance of USBHUB.SYS using a Wine-private<br>
>> >>> >> ioctl,<br>
>> >>> >> which would detect the driver for the device and launch a new<br>
>> >>> >> 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<br>
>> >>> >> 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<br>
>> >>> >> Morozov's<br>
>> >>> >> patch did things the Windows way: all drivers in one ntoskrnl<br>
>> >>> >> process<br>
>> >>> >> - this won't work properly in Wine for years, if ever, since<br>
>> >>> >> 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<br>
>> >>> >> 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<br>
>> >>> >> 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<br>
>> >>> >> can<br>
>> >>> >> support it. Our setupapi needs to be substantially improved to be<br>
>> >>> >> 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<br>
>> >>> >> of<br>
>> >>> >> cases where even class installers will be necessary too :-(.<br>
>> >>> >><br>
>> >>> >> Wine only sends DeviceIoControl to drivers. For anything<br>
>> >>> >> non-trivial,<br>
>> >>> >> other file-related user-space functions (at least ReadFile,<br>
>> >>> >> 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,<br>
>> >>> >> 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,<br>
>> >>> >> would<br>
>> >>> >> you like to help?<br>
>> >>> ><br>
>> >>> > I'd be willing to help if you want some assistance. I don't know<br>
>> >>> > 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>
><br>
><br>
<br>
</div></div>It's a human interface device, 1 control pipe and 1 interrupt pipe.<br>
Looks pretty simple. You could also use "winedump -j import" on the<br>
driver to see if it has any dependencies.<br>
<br>
I'll get working on the basics of USB first. If the device doesn't<br>
work on your tests after that, SSH access might be quicker and easier<br>
than intercontinental shipping.<br>
<br>
Thank you<br>
<font color="#888888">Damjan<br>
</font></blockquote></div><br clear="all">By driver, do you mean the wine-loaded driver, or whatever kernel module loads in linux?<br><br><br>Thanks<br><br>Tom<br>
<br>