On Tue, Sep 21, 2010 at 8:07 PM, Tom Spear <
speeddymon@gmail.com> wrote:
> On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic <
damjan.jov@gmail.com>
> wrote:
>>
>> 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
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >
>> >
>>
>> 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
>
>