2012/5/29 Frank Gevaerts <frank_at_gevaerts.be>
> 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
> 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)
A real pain.
> * 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)
Yes I think so. For the protocol, I would say yes ideally but there are
many possible variations in theory (HID, MSC, serial)
> * 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?
Then perhaps per SoC is already a good starting point I think.
> 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)
Go for it!
> "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