Alan Stern wrote:
That doesn't sound like a very good strategy in general. Configurations
don't have to be listed in any particular order; why should the first one
be treated specially?
There are only two ways possible for preferencing a configuration.
Ordering of the configurations or the configuration number in the
configuration itself. That number is commonly not used for expressing a
preference.
Yep. It bases on the assumption that the device developer was a fairly
smart one. For configurations that is acceptable even if it has been
tested only with Windows which uses the "simple" strategy.
How do you know what strategy Windows uses?
Simply by testing with a clean device which presents a high power
configuration followed by a low power configuration.
The idea is to have a device being able to draw the max power available
for charging purposes. It should allow the numerous idiots currently
simply drawing power from the USB without a device to build a valid
charger device.
The correct handling of such a device on a low power port should either
be to choose the low power configuration or not to configure the device.
In that situation the device disconnects and reconnects with the
configurations swapped.
Currently MacOS 9 correctly chooses the low power configuration. MaxOS X
does not configure the device and accepts it after the reconnect.
Windows XP switches off the port which prevents the reconnect.
Linux configures the device with the high power configuration.
Win XP only behaves badly. Linux is in blatant violation of the spec.
Now such a device may draw all of the 500 mA from a bus powered hub
already serving three other low power devices. A correctly implemented
hub will detect an overcurrent situation and switch off completely
dragging down (at least) three completely innocent devices.
A bugfix of this is really needed for Linux. It is a violation of the spec.
A simple patch only fixing this by not configuring he device would be
best because it has the best chances to get accepted to the next kernel
release. Anything beyond that is disputable (after all we are currently
in dispute over it :).
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users