From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Tue, 29 May 2012 22:11:25 +0200

Hi,

Apparently the Openmoko people distribute USB ids to selected projects
and communities that ask for them.
(see http://wiki.openmoko.org/wiki/USB_Product_IDs#Conditions
and http://laforge.gnumonks.org/weblog/2012/05/21/#20120521-open_registry_for_usb_and_mac_addrs)

I think we should seriously consider talking to them, but we need to
figure out what we want first.

Using the OF's USB ids has some disadvantages, such as:
* Operating systems making assumptions about the device (we've seen some
  linux distributions trying to use mtp on our devices. Also, OSes may
  have workarounds for bugs we don't have)
* Some car audio systems have ipod support using the USB IAP protocol,
  and refuse to use msc on such devices

I don't think there are actual disadvantages to using our own IDs, so the
main questions would be:

* Do we want one id per target (I think ideally we do)? Or even one id
  per "main" protocol (so we'd use e.g. a different id for MSC than for
  MTP (whenever we get MTP support)) (this would mosy probably be asking
  too much from the openmoko folks)

* If we can't get one id per target (which I think is not unlikely,
  we're talking 50+ ids *right now*, so we'd have to ask for a block of
  128 or 256 ids), is it still worth it? Should we then try to go for one
  id per SoC or per USB controller core? Can we make good use of just
  one or two ids?

I personally think that ideally we want one id per device, and that if
we manage to get that many we should use those ids by default, with a
setting to allow using the OF id. If we only get a few ids (or just
one), I think we should offer that id as a non-default option for those
people who are stuck with difficult hosts (such as the mentioned car
audio systems)

Thoughts?

Frank

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Received on 2012-05-29