<br><br><div class="gmail_quote">On Wed, Sep 22, 2010 at 2:26 AM, Damjan Jovanovic <span dir="ltr"><<a href="mailto:damjan.jov@gmail.com" target="_blank">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>On Wed, Sep 22, 2010 at 1:52 AM, Tom Spear <<a href="mailto:speeddymon@gmail.com" target="_blank">speeddymon@gmail.com</a>> wrote:<br>
> On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic <<a href="mailto:damjan.jov@gmail.com" target="_blank">damjan.jov@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Tue, Sep 21, 2010 at 8:07 PM, Tom Spear <<a href="mailto:speeddymon@gmail.com" target="_blank">speeddymon@gmail.com</a>> wrote:<br>
>> > On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic<br>
>> > <<a href="mailto:damjan.jov@gmail.com" target="_blank">damjan.jov@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear <<a href="mailto:speeddymon@gmail.com" target="_blank">speeddymon@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > Attached is the lsusb -v output, trimmed to only include the<br>
>> >> > pedometer's<br>
>> >> > info. I have many USB devices, so I didn't want to leave you to sort<br>
>> >> > 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<br>
>> >> > can<br>
>> >> > 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<br>
>> >> > <<a href="mailto:damjan.jov@gmail.com" target="_blank">damjan.jov@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> Please send the output of "lsusb -v" first so I can see if it's<br>
>> >> >> 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" target="_blank">speeddymon@gmail.com</a>><br>
>> >> >> wrote:<br>
>> >> >> > Now that I think about it, I have a webcam which the last<br>
>> >> >> > supported<br>
>> >> >> > windows<br>
>> >> >> > version was XP. I'm not using it for anything since I have another<br>
>> >> >> > one<br>
>> >> >> > which<br>
>> >> >> > is supported in 7 and linux, but I don't know if it's picked up in<br>
>> >> >> > 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" target="_blank">speeddymon@gmail.com</a>><br>
>> >> >> > wrote:<br>
>> >> >> >><br>
>> >> >> >> I have a USB pedometer that uploads the data to the internet. I<br>
>> >> >> >> could<br>
>> >> >> >> get<br>
>> >> >> >> another one and the driver software for you to play with. You<br>
>> >> >> >> have<br>
>> >> >> >> to<br>
>> >> >> >> be a<br>
>> >> >> >> registered member for a monthly fee to get one otherwise, but my<br>
>> >> >> >> job<br>
>> >> >> >> sponsors anyone that wants to get/stay in shape that works for<br>
>> >> >> >> them,<br>
>> >> >> >> so<br>
>> >> >> >> getting an extra pedometer is fine by me. I have been hoping for<br>
>> >> >> >> an<br>
>> >> >> >> opportunity to mention that it doesn't work, and this seems like<br>
>> >> >> >> 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" target="_blank">damjan.jov@gmail.com</a>><br>
>> >> >> >> wrote:<br>
>> >> >> >>><br>
>> >> >> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin<br>
>> >> >> >>> <<a href="mailto:eadurbin@gmail.com" target="_blank">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" target="_blank">damjan.jov@gmail.com</a>><br>
>> >> >> >>> > wrote:<br>
>> >> >> >>> >><br>
>> >> >> >>> >> When last I heard from Alexander Morozov (October 2009), he<br>
>> >> >> >>> >> wasn't<br>
>> >> >> >>> >> working on those patches much, and had no interest in sending<br>
>> >> >> >>> >> them<br>
>> >> >> >>> >> to<br>
>> >> >> >>> >> wine-patches.<br>
>> >> >> >>> >><br>
>> >> >> >>> >> I did some work on USB since then, and sent some patches<br>
>> >> >> >>> >> starting<br>
>> >> >> >>> >> from<br>
>> >> >> >>> >> around March 2010 (too many attempts to list, search for<br>
>> >> >> >>> >> 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<br>
>> >> >> >>> >> situation<br>
>> >> >> >>> >> 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<br>
>> >> >> >>> >> variation<br>
>> >> >> >>> >> of<br>
>> >> >> >>> >> libusb that had to be detected specifically, and some *nixes<br>
>> >> >> >>> >> 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<br>
>> >> >> >>> >> 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<br>
>> >> >> >>> >> other.<br>
>> >> >> >>> >> On<br>
>> >> >> >>> >> Windows there's a single address space for all drivers and<br>
>> >> >> >>> >> they<br>
>> >> >> >>> >> can<br>
>> >> >> >>> >> communicate amongst themselves. I don't think inter-driver<br>
>> >> >> >>> >> communication is that crucial initially, but it will be<br>
>> >> >> >>> >> eventually<br>
>> >> >> >>> >> (eg. last I heard, the iPod driver stacks on top of<br>
>> >> >> >>> >> USBSTOR.SYS,<br>
>> >> >> >>> >> and<br>
>> >> >> >>> >> multi-function USB devices can use a different driver for<br>
>> >> >> >>> >> each<br>
>> >> >> >>> >> interface - these may communicate among themselves with<br>
>> >> >> >>> >> private<br>
>> >> >> >>> >> ioctl<br>
>> >> >> >>> >> requests). The big problem with the multi process situation<br>
>> >> >> >>> >> is<br>
>> >> >> >>> >> hardware sharing: how do you set it up so each driver<br>
>> >> >> >>> >> accesses<br>
>> >> >> >>> >> its<br>
>> >> >> >>> >> own<br>
>> >> >> >>> >> and only its own hardware?<br>
>> >> >> >>> >><br>
>> >> >> >>> >> Drivers either start on system startup (Wine starts those<br>
>> >> >> >>> >> with<br>
>> >> >> >>> >> the<br>
>> >> >> >>> >> first process that starts), or get loaded on-demand as the<br>
>> >> >> >>> >> hardware<br>
>> >> >> >>> >> is<br>
>> >> >> >>> >> plugged in. Most drivers should install themselves to be<br>
>> >> >> >>> >> 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<br>
>> >> >> >>> >> (all<br>
>> >> >> >>> >> its<br>
>> >> >> >>> >> features are accessible via internal ioctls), and suggested<br>
>> >> >> >>> >> adding<br>
>> >> >> >>> >> the<br>
>> >> >> >>> >> features to USBD.SYS instead, which we already have and which<br>
>> >> >> >>> >> 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<br>
>> >> >> >>> >> one<br>
>> >> >> >>> >> -<br>
>> >> >> >>> >> great right? - but it has no idea which driver it got loaded<br>
>> >> >> >>> >> with,<br>
>> >> >> >>> >> nor<br>
>> >> >> >>> >> a straightforward way to determine which device(s!) that<br>
>> >> >> >>> >> driver<br>
>> >> >> >>> >> wants<br>
>> >> >> >>> >> to drive. Also, since most drivers only load on-demand, the<br>
>> >> >> >>> >> driver<br>
>> >> >> >>> >> will never load, and thus this won't work unless we load<br>
>> >> >> >>> >> those<br>
>> >> >> >>> >> drivers<br>
>> >> >> >>> >> on startup instead. The other approach, which I tried, was to<br>
>> >> >> >>> >> get<br>
>> >> >> >>> >> Wine's mountmgr.sys to detect USB devices using HAL, then<br>
>> >> >> >>> >> pass<br>
>> >> >> >>> >> them<br>
>> >> >> >>> >> to<br>
>> >> >> >>> >> a loaded-on-startup instance of USBHUB.SYS using a<br>
>> >> >> >>> >> 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<br>
>> >> >> >>> >> 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)<br>
>> >> >> >>> >> 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.<br>
>> >> >> >>> >> Another<br>
>> >> >> >>> >> possibility could be to keep drivers in separate processes,<br>
>> >> >> >>> >> but<br>
>> >> >> >>> >> allow<br>
>> >> >> >>> >> inter-process communication, but I see serializing IRPs<br>
>> >> >> >>> >> between<br>
>> >> >> >>> >> processes as being complex and very slow.<br>
>> >> >> >>> >><br>
>> >> >> >>> >> Driver installation is also quite a mission. Windows detects<br>
>> >> >> >>> >> that<br>
>> >> >> >>> >> the<br>
>> >> >> >>> >> hardware doesn't have a driver installed, and then generates<br>
>> >> >> >>> >> the<br>
>> >> >> >>> >> device ID and compatible IDs and searches .INF files for one<br>
>> >> >> >>> >> that<br>
>> >> >> >>> >> can<br>
>> >> >> >>> >> support it. Our setupapi needs to be substantially improved<br>
>> >> >> >>> >> to<br>
>> >> >> >>> >> be<br>
>> >> >> >>> >> able<br>
>> >> >> >>> >> to do the same, and some newdev.dll and manual INF parsing<br>
>> >> >> >>> >> work<br>
>> >> >> >>> >> to<br>
>> >> >> >>> >> install the driver may also be necessary, and I can already<br>
>> >> >> >>> >> 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<br>
>> >> >> >>> >> does<br>
>> >> >> >>> >> not<br>
>> >> >> >>> >> even exist yet, and would probably affects wineserver as<br>
>> >> >> >>> >> well.<br>
>> >> >> >>> >><br>
>> >> >> >>> >> Regression tests for ntosnkrl.exe and kernel drivers don't<br>
>> >> >> >>> >> exist,<br>
>> >> >> >>> >> and<br>
>> >> >> >>> >> are difficult to come up with, since we'd have to compile and<br>
>> >> >> >>> >> load<br>
>> >> >> >>> >> drivers on Windows and run tests that don't crash Windows<br>
>> >> >> >>> >> :-).<br>
>> >> >> >>> >><br>
>> >> >> >>> >> So the architecture for USB support is tricky to say the<br>
>> >> >> >>> >> least.<br>
>> >> >> >>> >> But<br>
>> >> >> >>> >> I'd still like to resume work on my USB patches some time<br>
>> >> >> >>> >> soon,<br>
>> >> >> >>> >> would<br>
>> >> >> >>> >> you like to help?<br>
>> >> >> >>> ><br>
>> >> >> >>> > I'd be willing to help if you want some assistance. I don't<br>
>> >> >> >>> > 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<br>
>> >> >> >>> my<br>
>> >> >> >>> Blackberry driver, but that's not going far quickly, since it's<br>
>> >> >> >>> a<br>
>> >> >> >>> multi-protocol device (modem, mass storage, and proprietary<br>
>> >> >> >>> protocols,<br>
>> >> >> >>> etc.). I've got a USB scanner that's unsupported by SANE, but<br>
>> >> >> >>> that<br>
>> >> >> >>> needs ReadFile/WriteFile which is a lot of work by itself. Same<br>
>> >> >> >>> with<br>
>> >> >> >>> USB flash sticks. I can get hold of an iPod but that's probably<br>
>> >> >> >>> the<br>
>> >> >> >>> most complex, needing to stack on top of USBSTOR.SYS IIRC.<br>
>> >> >> >>> Ironically<br>
>> >> >> >>> drivers for the easy hardware (USB mice) are unnecessary anyway,<br>
>> >> >> >>> since<br>
>> >> >> >>> the Linux drivers are good enough, and the Windows drivers<br>
>> >> >> >>> probably<br>
>> >> >> >>> need to be driven from user-space by bits Wine doesn't have.<br>
>> >> >> >>> Maybe<br>
>> >> >> >>> I<br>
>> >> >> >>> should give up and just get something partially working, add the<br>
>> >> >> >>> 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<br>
>> >> >> >>> 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<br>
>> >> >> >>> I/O<br>
>> >> >> >>> functions<br>
>> >> >> >>><br>
>> >> >> >>> That should get a very basic driver (that only uses the control<br>
>> >> >> >>> pipe)<br>
>> >> >> >>> working. I'll try to get some of this done later this<br>
>> >> >> >>> week/weekend.<br>
>> >> >> >>><br>
>> >> >> >>> Damjan<br>
>> >> >> >>><br>
>> >> >> >>><br>
>> >> >> >><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> >> 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>
>> >> Damjan<br>
>> ><br>
>> > By driver, do you mean the wine-loaded driver, or whatever kernel module<br>
>> > loads in linux?<br>
>> ><br>
>> ><br>
>> > Thanks<br>
>> ><br>
>> > Tom<br>
>> ><br>
>> ><br>
>><br>
>> The .sys file(s) used on Windows.<br>
>><br>
>> Damjan<br>
><br>
><br>
> Looking at device manager in windows 7, I see the device, but when I try to<br>
> look at driver details, it says no driver files are required or have been<br>
> loaded for this device. It is actively used, however. I'm thinking the<br>
> software to upload the data from the device interfaces with the device<br>
> directly, based on that. I also checked a clean wine drive c with just the<br>
> software for this pedometer installed, and didn't see anything that appeared<br>
> to have been added, driver-wise, by the installer. However, the software<br>
> cannot read the serial number of the device under wine, whereas it can under<br>
> Windows.<br>
><br>
> Thanks<br>
><br>
> Tom<br>
><br>
<br>
</div></div>It could be using the generic human interface device driver provided<br>
by Microsoft, the older user-space USB IOCTLs, or the Windows XP and<br>
later UMDF (user mode driver framework).<br>
<br>
A +file trace on Wine would tell us what it's doing.<br>
<br>
Thanks<br>
<font color="#888888">Damjan<br>
</font></blockquote></div><br>I will try that when I get off of work. I'm definitely curious to see
how it is trying to read the serial number and other data from the
pedometer itself. BTW, I have SSH setup already, as I remote in from
work to monitor some things, but I prefer to use public keys, so if you
don't already have one generated, you'll need one when it is time for
you to login and tinker. ;-)<br>
<br>Results in the morning.<br><br clear="all">Thanks<br><br>Tom<br>