On Fri, Apr 8, 2016 at 1:56 PM, Martin Koegler <martin.koegler@xxxxxxxxx> wrote: > On Fri, Apr 08, 2016 at 11:21:57AM -0400, Adam Goode wrote: > > So there are 2 alternatives I can think of: > > > > option 1: introduce snd_seq_client_info_get_pid_2() and leave the > existing > > function alone. This new function can return a new constant, > > SND_SEQ_CLIENT_INFO_PID_UNKNOWN for missing kernel support. Same for > card. > > option 2: introduce snd_seq_client_info_pid_known() that returns a bool > if > > there is kernel support. Same for card. > > I wouldn't implement option 1. Using that methode for API changes will > result in lots of rarely used functions. > > Chrome will probable need that information to enable a fallback-code - if > a application has no fallback code, > it has no need for different returncodes. In a few years, most > distributions will likely ship kernel including that functions, > so there is no need to for fallback-code and the kernel support check any > more. > > Why not a snd_seq_client_info_get_capatibilites() returing bit flags: > .._CAP_CARD_NUMBER | .._CAP_PID ? > > This approach is fine by me as well, though it does introduce more constants and bitwise logic. Adam > Regards, > Martin > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
