|
||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | |||||||
See:
Description
| Class Summary | |
| DeviceImpl | Provides access to a USB device. |
| Windows | Provides access to native USB host object for this process. |
This package has a partial Windows implementation of a usb.core.Host object, bootstrapping support, and other classes leveraging Windows USB support. At this writing, only control traffic really works.
The accompanying source to jusbFWin.dll native code passes userspace Windows ioctl calls to a custom 'filter' driver (fwupdate.sys) that can sit on top of a full Windows device driver like the composite device driver (usbhub.sys) or the generic fwusbstub.sys. The full driver is responsible for handling plugging, disconnect, and power state charges, while the filter driver just passes along control message URBs. The dll and drivers were built with Visual C++ 6.0, and currently attach only to FingerWorks products (vendor ID 0xe97). To use with other devices, the appropriate product and vendor IDs need to be changed in the inf file (currently fingerworks.inf) as well as the DLL. The DLL really needs an API for selecting which Vendor IDs to scan for. (Or for just exposing all the devcies that appear, which is how to make the API work best.)
The rest of this package overview is a summary of Windows-specific issues you may need to know about.
...does not yet exist, but adding it to the DLL and filter driver should be straightforward. Just need to add appropriate ioctl's with properly-formatted URBs. The existing DLL only supports standard descriptor requests and vendor control requests.
Devices found during driver scanning are registered in a flat list, each as the root device on its own bus. Nothing is known about hubs or the real USB bus topology, since Windows hides hubs behind its usbhub.sys driver, and unlike Linux's usbdevfs, does not provide a file system topology reflecting the physical USB hub/device hierarchy. So the usb.core.Hub and usb.core.PortIdentifier classes are useless (and should be avoided!) with this current Windows implementation. However, usb.core.Device, usb.core.Descriptor, usb.core.DeviceDescriptor, usb.core.ControlMessage, usb.core.Endpoint, and usb.core.Interface should work for control messaging at least.
The Watcher thread within usb.windows.Windows calls out to the DLL every second or so via scanForFWDevices() to scan for removal or attachment of devices. The dll calls back newFWDeviceAvailable() or existingFWDeviceRemoved() on the same thread for each device change. If the filter driver fwupdate.sys is not yet installed for a detected FingerWorks device on a particular port (yes, Windows must re-register a device for each port :(, the dll also invokes fingerworks.inf to install the appropriate drivers. This may take awhile, and cause various driver installation wizards to pop up for user approval.
|
||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | |||||||