Re: usb function framework

[David Brownell <[email protected]>]
> 
> The notion of "dynamic" pluggability is problematic in terms
> of what the USB spec presents as the definition of a device,
> with a given pair of vendor and product IDs ... it's expected
> to be fixed function, where SET_CONFIGURATION is used to
> change device capabilities.  (Or SET_INTERFACE.)

When I say "dynamic" here, I mean mostly "in response to user
settings".  For example, perhaps you have an option to enable or
disable usb mass storage, or enable or disable a debugging interface.

In standard configuration "from the factory", the feature is off and
not present at all, but if the user turns it on, I'd expect the
device to disconnect from USB, adjust its configuration (possibly
changing VID/PID to work around win32 oddities with driver assignments,
etc), and reconnect to USB with the new configuration.

For mass storage, one can cheat a bit here and just have the mass
storage device be removeable and have it "eject" when turned off.
For other functions, one may want them to just not be there at all
when not enabled -- debugging features that don't map to standard 
class drivers and would potentially confuse users when something 
like win32 starts popping up driver install dialogs at them.

Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel