On Wed, Sep 22, 2010 at 2:26 AM, Damjan Jovanovic <[email protected]>wrote:
> On Wed, Sep 22, 2010 at 1:52 AM, Tom Spear <[email protected]> wrote: > > On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic <[email protected]> > > wrote: > >> > >> On Tue, Sep 21, 2010 at 8:07 PM, Tom Spear <[email protected]> > wrote: > >> > On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic > >> > <[email protected]> > >> > wrote: > >> >> > >> >> On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear <[email protected]> > >> >> wrote: > >> >> > 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 > >> >> > <[email protected]> > >> >> > 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 <[email protected]> > >> >> >> 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 < > [email protected]> > >> >> >> > 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 > >> >> >> >> <[email protected]> > >> >> >> >> wrote: > >> >> >> >>> > >> >> >> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin > >> >> >> >>> <[email protected]> > >> >> >> >>> wrote: > >> >> >> >>> > > >> >> >> >>> > > >> >> >> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic > >> >> >> >>> > <[email protected]> > >> >> >> >>> > 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 > >> >> >> >>> > >> >> >> >>> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> >> > >> >> It's a human interface device, 1 control pipe and 1 interrupt pipe. > >> >> Looks pretty simple. You could also use "winedump -j import" on the > >> >> driver to see if it has any dependencies. > >> >> > >> >> I'll get working on the basics of USB first. If the device doesn't > >> >> work on your tests after that, SSH access might be quicker and easier > >> >> than intercontinental shipping. > >> >> > >> >> Thank you > >> >> Damjan > >> > > >> > By driver, do you mean the wine-loaded driver, or whatever kernel > module > >> > loads in linux? > >> > > >> > > >> > Thanks > >> > > >> > Tom > >> > > >> > > >> > >> The .sys file(s) used on Windows. > >> > >> Damjan > > > > > > Looking at device manager in windows 7, I see the device, but when I try > to > > look at driver details, it says no driver files are required or have been > > loaded for this device. It is actively used, however. I'm thinking the > > software to upload the data from the device interfaces with the device > > directly, based on that. I also checked a clean wine drive c with just > the > > software for this pedometer installed, and didn't see anything that > appeared > > to have been added, driver-wise, by the installer. However, the software > > cannot read the serial number of the device under wine, whereas it can > under > > Windows. > > > > Thanks > > > > Tom > > > > It could be using the generic human interface device driver provided > by Microsoft, the older user-space USB IOCTLs, or the Windows XP and > later UMDF (user mode driver framework). > > A +file trace on Wine would tell us what it's doing. > > Thanks > Damjan > 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. ;-) Results in the morning. Thanks Tom
