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
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.comwrote:
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:
- libusb integration
- driver loading hacks
- driver -> devices lookup
- usb bus enumeration for devices
- create pdo and fdo for each device
- AddDevice to driver
- 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
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.comwrote:
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:
- libusb integration
- driver loading hacks
- driver -> devices lookup
- usb bus enumeration for devices
- create pdo and fdo for each device
- AddDevice to driver
- 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
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:
- libusb integration
- driver loading hacks
- driver -> devices lookup
- usb bus enumeration for devices
- create pdo and fdo for each device
- AddDevice to driver
- 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
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.comwrote:
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:
- libusb integration
- driver loading hacks
- driver -> devices lookup
- usb bus enumeration for devices
- create pdo and fdo for each device
- AddDevice to driver
- 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
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:
- libusb integration
- driver loading hacks
- driver -> devices lookup
- usb bus enumeration for devices
- create pdo and fdo for each device
- AddDevice to driver
- 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
On Tue, Sep 21, 2010 at 10:04 AM, Damjan Jovanovic damjan.jov@gmail.com wrote:
... 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.
That's an interesting plan... If you're interested I might be able to convince the powers that be here to permit you SSH access to a machine connected to a ZEMAX license key (a SafeNet Sentinel USB key). It's a vendor-specific device but all the software is freely download-able.
Erich Hoover ehoover@mines.edu
On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic damjan.jov@gmail.comwrote:
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:
- libusb integration
- driver loading hacks
- driver -> devices lookup
- usb bus enumeration for devices
- create pdo and fdo for each device
- AddDevice to driver
- 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
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
The .sys file(s) used on Windows.
Damjan
On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic damjan.jov@gmail.comwrote:
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
The .sys file(s) used on Windows.
Damjan
Looking at device manager in windows 7, I see the device, but when I try to look at driver details, it says no driver files are required or have been loaded for this device. It is actively used, however. I'm thinking the software to upload the data from the device interfaces with the device directly, based on that. I also checked a clean wine drive c with just the software for this pedometer installed, and didn't see anything that appeared to have been added, driver-wise, by the installer. However, the software cannot read the serial number of the device under wine, whereas it can under Windows.
Thanks
Tom
On Wed, Sep 22, 2010 at 1:52 AM, Tom Spear speeddymon@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic damjan.jov@gmail.com wrote:
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
The .sys file(s) used on Windows.
Damjan
Looking at device manager in windows 7, I see the device, but when I try to look at driver details, it says no driver files are required or have been loaded for this device. It is actively used, however. I'm thinking the software to upload the data from the device interfaces with the device directly, based on that. I also checked a clean wine drive c with just the software for this pedometer installed, and didn't see anything that appeared to have been added, driver-wise, by the installer. However, the software cannot read the serial number of the device under wine, whereas it can under Windows.
Thanks
Tom
It could be using the generic human interface device driver provided by Microsoft, the older user-space USB IOCTLs, or the Windows XP and later UMDF (user mode driver framework).
A +file trace on Wine would tell us what it's doing.
Thanks Damjan
On Wed, Sep 22, 2010 at 2:26 AM, Damjan Jovanovic damjan.jov@gmail.comwrote:
On Wed, Sep 22, 2010 at 1:52 AM, Tom Spear speeddymon@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic damjan.jov@gmail.com wrote:
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
The .sys file(s) used on Windows.
Damjan
Looking at device manager in windows 7, I see the device, but when I try
to
look at driver details, it says no driver files are required or have been loaded for this device. It is actively used, however. I'm thinking the software to upload the data from the device interfaces with the device directly, based on that. I also checked a clean wine drive c with just
the
software for this pedometer installed, and didn't see anything that
appeared
to have been added, driver-wise, by the installer. However, the software cannot read the serial number of the device under wine, whereas it can
under
Windows.
Thanks
Tom
It could be using the generic human interface device driver provided by Microsoft, the older user-space USB IOCTLs, or the Windows XP and later UMDF (user mode driver framework).
A +file trace on Wine would tell us what it's doing.
Thanks Damjan
I will try that when I get off of work. I'm definitely curious to see how it is trying to read the serial number and other data from the pedometer itself. BTW, I have SSH setup already, as I remote in from work to monitor some things, but I prefer to use public keys, so if you don't already have one generated, you'll need one when it is time for you to login and tinker. ;-)
Results in the morning.
Thanks
Tom
-
Damjan Jovanovic -
Erich Hoover -
Tom Spear