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

Reply via email to