On Fri, Nov 29, 2019 at 8:01 AM Jaroslav Kysela <perex@xxxxxxxx> 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@xxxxxxxxxxxx> > >> --- > >> 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@xxxxxxxx> > Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
