[alsa-devel] Separate input and output jacks for one UCM device?

[Takashi Iwai]

At Thu, 19 Mar 2015 14:22:18 +0000,
Jie, Yang wrote:
> 
> > From: Takashi Iwai [mailto:tiwai at suse.de]
> > Sent: Thursday, March 19, 2015 10:10 PM
> > To: Liam Girdwood
> > Cc: Tanu Kaskinen; alsa-devel at alsa-project.org; Arun Raghavan; Lu, Han;
> > Mark Brown; Jie, Yang
> > Subject: Re: Separate input and output jacks for one UCM device?
> > 
> > At Thu, 19 Mar 2015 09:15:59 +0000,
> > Liam Girdwood wrote:
> > >
> > > On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
> > > > Hi Liam and alsa-devel,
> > > >
> > >
> > > I've added a few others on the CC that would be interested.
> > >
> > > > My understanding is that a UCM device can represent a thing that has
> > > > both input and output (I don't particularly like that, but it's too
> > > > late to complain).
> > >
> > > Yes, but it can also represent simplex devices too e.g.
> > > "Headset-Speakers" and "Headset-Mic". There are not any hard rules
> > > here, but most examples are using duplex devices as historically UCM
> > > came from the phone ecosystem use cases.
> > >
> > > > How likely do you think that there are or there will be some drivers
> > > > that expose separate input and output jack kcontrols for a headset
> > > > jack, to differentiate between headphones/headset/microphone? My
> > > > understanding is that jack kcontrols store only booleans, so there's
> > > > no way to distinguish between headphones and a headset with just one
> > kcontrol.
> > > >
> > >
> > > This sounds like we need to extend the jack kcontrol so that we can
> > > differentiate between Headphones and Headset unless the kcontrol
> > > naming was intended to differentiate and define the jack type ?
> > 
> > Yeah, that's what we really need to face seriously now to.
> > Keyon is working on merging input and kctl jacks, and this is the biggest
> > problem that has to be sorted out.
> > 
> > As far as I understand correctly, so far ASoC drivers also report headset as
> > boolean (the bits are multiple, but reports are either zero or N bits).  So, we
> > agreed on creating boolean "Headset" kctls.
> > 
> > One option is to provide multiple boolean kctls ("Headset Mic Jack").
> [Keyon] how about using "Headset Jack Mic" and "Headset Jack Speakers"?
> Then we can understand of that both these two kctls are belong to the
> Headset Jack.

This would be OK, too.  BTW, an obvious drawback of splitting boolean
kctls is that you'll receive multiple events.  For example, when
triggering a headset, both headset mic and headset speaker ctls will
get an event.


Takashi