On Mon, Jun 6, 2016 at 10:01 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > On Mon, 06 Jun 2016 15:57:33 +0200, > Adam Goode wrote: > > > > On Fri, Apr 8, 2016 at 3:53 PM, Adam Goode <agoode@xxxxxxxxxx> wrote: > > > > > 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. > > > > > > > > Since returning to this problem after a while, I've realized that we > don't > > need any changes at all to alsa-lib. This test is equivalent to what is > > needed: > > > > snd_seq_get_client_info(seq, info); // get our client's info > > bool client_pid_supported = snd_seq_client_info_get_pid(info) != -1; // > do > > we know our own PID? > > Ah, yes, it works. I thought of another, e.g. checking /dev/sequencer > version ioctl, but yours works more nicely. > > > It might be helpful to put this into the documentation, but otherwise I > > think this is fine. > > A patch is always welcome :) > > Hi, I just sent a documentation patch. :) Thanks, Adam > > thanks, > > Takashi > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
