On Mon, Apr 4, 2016 at 10:54 AM, Takashi Iwai tiwai@suse.de wrote:
On Fri, 01 Apr 2016 23:15:58 +0200, Martin Koegler wrote:
On Fri, Apr 01, 2016 at 01:33:50PM -0400, Adam Goode wrote:
When trying to get the pid or card of a client, the get functions will return -1 if there is no pid or card for a client. Clients have zero or one of these, so -1 is correct for these cases. But we also need to
detect
the case where the kernel cannot tell us if there is a card or pid, so that userspace can fallback to probing this information in the old way.
Its a pity, that alsa-lib 1.1.1 has just been released, which just
returns -1.
If the time between releases is really about 2 kernel releases, you will
very likely
have to cope with the old API for some time.
Strictly speaking, for the function behavior change, we'd need a new API function and deprecated the old one eventually. But, this case is in a gray zone; the function definition doesn't prohibit to return an error value yet, but the change like this is incompatible with the current aconnect code, which is likely regarded as a template for other programs.
OTOH, this is a pretty new API function, and it might be not too bad to fix the usage in the early stage, especially when it's a good improvement of the function behavior.
So, for now, I'm inclined to take this change with a slight risk of breakage. But I'm open for more arguments, and would like to hear any objections.
Thanks for reviewing this. As an alternative, we could introduce a completely new function that either returns the kernel interface version (which means client code would have to keep a mapping of versions -> implemented features) or returns the implementation state of this particular feature. In some ways that would be slightly more straightforward for Chromium, since I could probe ALSA once for the kernel state using a function specifically for that purpose. But it doesn't matter to me either way.
Thanks,
Adam
thanks,
Takashi