Clemens,
> > We finally have the case of a device which talks two different protocols,
> > depending on the firmware loaded, and a driver which hooks in triggered
> > by the v/p ids assuming proprietary protocol being talked.
>
> No, the driver additionally checks for the interface class. With class
> 0xff ("vendor specific", Midiman's firmware), the proprietary protocol is
> used. With class 1 (audio, your GPL firmware), the standard protocol is
> used. I added the USB_DEVICE_VENDOR_SPEC macro specifically to avoid any
> conflicts between the two firmware versions.
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. Perhaps it can be
further secured by an appropriate comment, as the potential clash is not
obvious.
> > Now i write to ask for your advice how to do things the right way. I fear
> > that picking a GNU id would overdo and overcomplicate matters. I'm not
> > even certain about the registration process or whether fee become due to
> > usb.org.
>
> <http://www.usb.org/developers/vendor.html>: $1500 for two years
Well - I could simply pick a free one, eg. FFFF, and announce that claim to
usb.org, independent of their procedure and fees. It is their duty too, to
keep the namespace clear and the registration process resonable, which
clearly means $0 for freeware for two years, whether they like it or not. But
again, i think that it would overdo the matter unless we have a lot of such
clashes and a greater potential that something gets broken.
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,
which i cannot help. The other way round, it would work fine on Linux or
other free OSes that use alsa together with my firmware. This means your
support of the protocol improves matters and closes a potential problem at
least for Linux.
> > I'm also not clear how the vendor/product id has to be understood. Is it
> > for the physical device (in which case it cannot be changed) or to the
> > firmware?
>
> It's for the firmware. There are different id's for Midisport devices with
> and without firmware (have a look at the Windows driver .inf files).
Sure from that fact. I was checking for that earlier in the usb specs, and the
authors were not aware of the possibility of re-enumberation and non-vendor
firmware, so the specs are absolutely unclear about that.
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.
-lars
-------------------------------------------------------
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
