[alsa-devel] [PATCH 02/11] ucm: docs: Add JackType value

[Curtis Malainey]

On Fri, Nov 29, 2019 at 8:01 AM Jaroslav Kysela <perex at perex.cz> wrote:
>
> Dne 11. 11. 19 v 14:39 Jaroslav Kysela napsal(a):
> > Dne 07. 11. 19 v 2:57 Curtis Malainey napsal(a):
> >> Identifies the type of jack and how it should be accessed
> >>
> >> Signed-off-by: Curtis Malainey <cujomalainey at chromium.org>
> >> ---
> >>    include/use-case.h | 3 +++
> >>    1 file changed, 3 insertions(+)
> >>
> >> diff --git a/include/use-case.h b/include/use-case.h
> >> index 2051bd40..3208cc30 100644
> >> --- a/include/use-case.h
> >> +++ b/include/use-case.h
> >> @@ -322,6 +322,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,
> >>     *        configuration that doesn't belong to UCM configuration files.
> >>     *   - JackName
> >>     *      - Input name is the input device name for the jack
> >> + *   - JackType
> >> + *      - Specifies whether the jack is accessed via hctl or gpio and therefore
> >> + *        only carries the possible values of "gpio" or "hctl"
> >>     */
> >>    int snd_use_case_get(snd_use_case_mgr_t *uc_mgr,
> >>                         const char *identifier,
> >>
> >
> > What is meant with the "gpio" type? The standard input device interface? I
> > believe it should be "inputdev" and "ctl" (hctl is just interface on top of
> > ctl and the application can access the jack through snd_ctl functions, too.
>
> I see (when I was cleaning this extra Chrome stuff in the ucm profiles) that
> it's related to the gpio (general purpose i/o pin interface) in the linux
> kernel. The JackSwitch is probably also related and defines the pin number
> where the application should watch for the jack state. In this case, it would
> be probably more nice to follow the JackControl and JackDev and define the pin
> number through JackGPIO or something like that. We will cover all three
> posibilities: ALSA control interface, Input interface, GPIO interface .
>
>                                         Jaroslav
Initially that was our thoughts too but then we realized that in the
event of a new theoretical input subsystem "foo" that can be used for
jack detect then we would need to create another field for that as
well. This reduces the need for having a field for every theoretical
subsystem in the future and only then requires a new value.
>
> --
> Jaroslav Kysela <perex at perex.cz>
> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.