On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear <
speeddymon@gmail.com> 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 <
damjan.jov@gmail.com>
> 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 <
speeddymon@gmail.com> 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 <
speeddymon@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.jov@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin <
eadurbin@gmail.com>
>> >>> wrote:
>> >>> >
>> >>> >
>> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
>> >>> > <
damjan.jov@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
>> >>>
>> >>>
>> >>
>> >
>> >
>
>