On 01/04/14 04:47, Daniel Mack wrote:
Yeah, now that you changed the code to handle an arbitrary amount of endpoints, you could as well change all user of QUIRK_AUDIO_FIXED_ENDPOINT over to the new one, and initialize .epmulti to 1. That should already work, right? (Though, I have to mention that I'm unhappy with the name of that variable :)).
Given Mark's concerns, I'm not sure this will work for devices which share an interface with multiple endpoints where the endpoints have different properties. I think my code only works when the multiple endpoints have the same properties apart from the endpoint #.
For example, the existing code which brings up a fixed interface assumes that there is only one endpoint and refers to it via an index which is usually hardcoded to 0. So most of the quirk would be ignored as only the data for the first mentioned endpoint would be used for certain functions. For example, functions such as get_endpoint(alts, 0) etc. This is the major stumbling block that Mark is referring to I think. What are your thoughts on this one Daniel? Have you seen Mark's untested code? It's part of this thread and seems to address this problem.
A const void* can hold any kind of struct, and you need to cast it back to your struct eventually anyway. Thinking about it again, I don't like the idea of an extra member in struct snd_usb_audio_quirk either. What would be nicer is to introduce something like this:
struct audioformats { unsigned int n_formats; const struct audioformat *format; };
Yes, this looks good, I can use this idea.
Also, you can write the actual quirk handler so that it loops over the array entries, so you can re-use the code for both QUIRK_AUDIO_FIXED_MULTI_ENDPOINTS and QUIRK_AUDIO_FIXED_ENDPOINT.
Do you follow? :)
Yes, it makes sense.