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 <speeddy...@gmail.com> 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 <damjan....@gmail.com>wrote: > >> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin <eadur...@gmail.com> wrote: >> > >> > >> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic < >> damjan....@gmail.com> >> > 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 >> >> >> >