Ok, the 0.10 API, common RI, and Linux RI (which are all in CVS only) are essentially working at a beta level. The UsbView (swing) app is updated for the new API methods (mainly offset/length and using ControlUsbIrps instead of Requests). The JavaDOC is linked to from the main page (http://javax-usb.org/). Besides the changes I suggested long ago, there a few more; if anyone has comments, please reply! Also, if you have time, please try out the implementation.
-All Descriptors' methods are renamed to exactly match the field listed in the USB spec. For example: InterfaceDescriptor.getInterfaceNumber() -> bInterfaceNumber() ConfigDescriptor.getConfigNumber() -> bConfigurationValue() and so on. My reasoning is, there is no need to reinvent a set of names to describe the same set of values; simply using the exact names as specified in the USB spec makes everything more consistent and easier to remember. That's my reasoning at least, does anyone else feel differently? :) -Added bString to StringDescriptor, and getString throws UnsupportedEncodingException. The bString is just the raw byte[], which the StringDescriptor should have. The actual String though, has to be translated and it's possible the JVM doesn't have the encoding to translate it. -Changed Request to ControlUsbIrp. The methods on ControlUsbIrp are exactly as defined in the USB spec - bmRequestType, bRequest, etc. UsbPipes that are Control-type pipes should only accept ControlUsbIrps, and UsbDevice has XXXsubmit() methods requiring ControlUsbIrp(s). -Add default implementation of UsbIrp and ControlUsbIrp in the /util/ package. Also, add creation methods to UsbPipe/UsbDevice. Previously, UsbServices had a method to get a UsbIrp factory, and that was the only way to get an UsbIrp instance (cleanly). Having the default implementation is important, so the user can extend them; but, the UsbPipe/UsbDevice implementation for this RI (and probably other implementations) will need to extend them also with internal implementation methods (and 'wrap' the UsbIrp passed in). So the UsbPipe creation methods allow the user to get a 'preferred' instance of UsbIrp/ControlUsbIrp that the UsbPipe/UsbDevice implementation can handle in an optimized manner. I can go into more detail if anyone is interested...and I'd certainly like to hear if anyone thinks either the UsbPipe.createUsbIrp methods or the default UsbIrp implementations should go away...Now is the time to discuss it! :) -Change UsbDevice.getSpeedString() to UsbDevice.getSpeed(). Device speed is now represented by a set of Objects defined in UsbConst. UsbUtil has a getSpeedString() conversion method. This way the user can directly compare, i.e. UsbConst.DEVICE_SPEED_LOW == usbDevice.getSpeed() -Remove 'alternate' from UsbInterface alternate-setting methods. The word 'alternate' was redundant (the word 'setting' is enough) and made the method names too long. -Added util/StandardRequest.java, which is just a utility class that makes performing Standard Requests easy. -Changed all Events to use a _copy_ of the data buffer (but keep the orginal UsbIrp/ControlUsbIrp, if applicable). This is because if the original buffer is passed to all Listeners, it's quite likely that one will modify it and then the other Listeners will have a modified (corrupted) buffer that will cause problems. If you care about performance, you shouldn't be using Listeners anyway - use your own Thread to keep track of completed UsbIrps. I'm trying to decide about these points though: -The fact that interfaces have alternate settings is a bit complicated; and to add to that, the InterfaceDescriptor doesn't really include any setting information besides bAlternateSetting (the setting number). This means that UsbInterface still has getNumSettings(), which is a bit confusing, since all the other getNumXXX() methods were moved into the Descriptor that they belonged in. Should getNumSettings() be moved into the InterfaceDescriptor, even though it really isn't part of the descriptor? -UsbEndpoint has 2 methods, getDirection() and getType(), that seem to belong to the EndpointDescriptor, but don't. They are only portions of other methods - getDirection() is simply ENDPOINT_DIRECTION_MASK & bEndpointAddress() and getType() is ENDPOINT_TYPE_MASK & bmAttributes() Does anyone else think these should be moved into the EndpointDescriptor, even though they aren't really fields of the descriptor? There's probably more, but that's all I can think of at the moment and this email is way too long already anyway ;-) Thanks everyone! -- Dan Streetman [EMAIL PROTECTED] -------------------------------------------------- 186,282 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ javax-usb-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
