USB Device Support

[Damjan Jovanovic]

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