Lars Doelle wrote: > > No, the driver additionally checks for the interface class. (...) > > Ok, Clemens, that definitely calms my fears. Because we're doing in freeware, > and many people work on and extend the programs, my experience is, that a > product has to be written so, that tricks like that should be unlikely to be > broken by innocent changes of a contributor who wants to be helpful. In this > case it might especially suggest itself to someone not aware of the clash to > "beautify" the code by reordering the detection process.
There is no such problem because the id_table entries are mutually exclusive because they specify different interface classes. > As things are, only the windows driver in a dual boot environment would be > affected that way, as things are now, since the firmware survives reboot, > (...) > I'd actually blame the vendor for that clash as their firmware makes > unnecessary use of a proprietary protocol, where something class specific is > available, a doing i consider plain evil. Blaming Midiman's drivers is easy as that's the place where odd behaviour/ crashes will occur. And we can innocently ask, "Why, your USB MIDI driver is not USB MIDI compliant?" ;-) However, not following the specs is standard practice. The USB MIDI specification was written by Roland, and if you want to know whether they bother to supply class-specific descriptors for their own devices, have a look at alsa-kernel/usb/usbquirks.h. BTW: Is there an official web page for your drivers? Have you considered creating a SourceForge project? Regards, Clemens ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
