On Wed, Oct 09, 2002 at 08:33:35PM -0400, Johannes Erdfelt wrote: > > I think the big remaining question right now is determining how a > configuration should be elected. > > In my devfs patch a long time ago, I had created an election process > where drivers could specify the priority of their support. The highest > priority won. > > Here's the thought process I originally used: > - Multiple configurations are rare > - Devices won't change substantially between configurations (ie won't go > from a keyboard to a cdrom) > - Used typically to provide different levels of support depending on bus > or host limitations (ie config for lower power, config for generic > printer class, but another one for a superset ala uss720) > > If that's the case, a priority would probably work well. > > Can anyone think of a reason to use different configurations outside of > what I was thinking?
Device has two different configurations, one for when connected to a Windows host, and one for when connected to a Unix host. Yeah it's not the nicest thing, but it's what I'm thinking is about to happen to a device that I'm watching in the design phase. Main reason for this is because of Windows "Generic HID" interface isn't available on Linux, and that it's much easier to just create a interface with 2 bulk endpoints (one in, one out) and use libusb to talk to it, on a Unix box. So one of the OSs is going to have to change configuration somehow... > This also brings up the question of if we should allow the configuration > to change miduse (meaning after drivers have bound already to any > interfaces)? I don't think so, unless we want to simulate the interface disconnect to any connected drivers before we switch. Hm, that might be the easiest thing to do anyway. thanks, greg k-h ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
