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
