[alsa-devel] [PATCH - alsa-lib 1/1] Change card/pid get functions to return -ENOSYS if the kernel is too old

[Adam Goode]

On Mon, Jun 6, 2016 at 10:01 AM, Takashi Iwai <tiwai at suse.de> 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 at google.com> wrote:
> >
> > > On Fri, Apr 8, 2016 at 1:56 PM, Martin Koegler <
> martin.koegler at chello.at>
> > > 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
>