On 29/03/14 16:01, Mark Hills wrote:
I'm a bit late to this, but I think a more generic quirk is necessary.
Thanks Mark, I don't know much about other devices, but I have provided some comments about my latest code: http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140329/ba...
Or does some kind of spec define that these should be applied to the first endpoint and that all will be affected?
I used educated guesses to make the Mbox 1 functional:
I set the altsetting of the interface based on the value provided in the first endpoint entry of the quirk, (since they must be all the same for a shared interface): + alts = &iface->altsetting[fp[0]->altset_idx];
This works for any device where the interface is shared across multiple endpoints, right? Otherwise you wouldn't use this new quirk type.
After reading all the quirk data and adding streams one by one, I went on to configure the interface based on the quirk data for the first entry: + usb_set_interface(chip->dev, fp[0]->iface, 0); + snd_usb_init_pitch(chip, fp[0]->iface, alts, fp[0]); + snd_usb_init_sample_rate(chip, fp[0]->iface, alts, fp[0], fp[0]->rate_max);
I assumed that the supported rates for all interfaces was the same and that they could be read from the first endpoint entry in the quirk. I know, most of the quirk data is ignored, but they share the same interface so most of it is redundant anyway, isn't it?
I can't see what limitations this multi-endpoint quirk type has that might need to be adjusted for other devices. Can you provide an example of a device that uses multiple endpoints within a single interface whose supported rates differ between endpoints? If you can, then I also think we need a better model. If you can't, is it because it is impossible?
Damien