[alsa-devel] Headset button mapping in the kernel

[alsa-devel] Headset button mapping in the kernel

[Curtis Malainey]

Hello ALSA Devs,

I am looking to get some feedback/ideas on a possible change to
headset button mapping. Locally we are carrying patches that implement
the mappings in the machine driver (which we understand you do not
want upstream.) We are looking to see if we can add a new API
(something like a sysfs path potentially) to have userspace pass in
the mapping, if it chooses to, so the mapping can still be done in the
kernel. That way we can carry just the config locally and remove some
of the kernel patches we are carrying locally. Thanks.

Curtis
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Mads Lønsethagen]

Hi!

Is this related to Android Wired Audio Headset Specification? Just 
wondering (I asked about it last month[1]).

Would be neat if it were possible to get headphone buttons working on 
Linux in general.

- Mads


On 25.11.2019 20:25, Curtis Malainey wrote:
> Hello ALSA Devs,
> 
> I am looking to get some feedback/ideas on a possible change to
> headset button mapping. Locally we are carrying patches that implement
> the mappings in the machine driver (which we understand you do not
> want upstream.) We are looking to see if we can add a new API
> (something like a sysfs path potentially) to have userspace pass in
> the mapping, if it chooses to, so the mapping can still be done in the
> kernel. That way we can carry just the config locally and remove some
> of the kernel patches we are carrying locally. Thanks.
> 
> Curtis
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Takashi Iwai]

On Mon, 25 Nov 2019 20:25:53 +0100,
Curtis Malainey wrote:
> 
> Hello ALSA Devs,
> 
> I am looking to get some feedback/ideas on a possible change to
> headset button mapping. Locally we are carrying patches that implement
> the mappings in the machine driver (which we understand you do not
> want upstream.) We are looking to see if we can add a new API
> (something like a sysfs path potentially) to have userspace pass in
> the mapping, if it chooses to, so the mapping can still be done in the
> kernel. That way we can carry just the config locally and remove some
> of the kernel patches we are carrying locally. Thanks.

I guess you're referring to the mapping that is currently done via
snd_jack_set_key() calls?  If so, an additional sysfs or such
interface would be handy, and it should be relatively easy.

But a proper sysfs entry design is another question; it's an array,
and this can be set for each jack object, so not that trivial.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Curtis Malainey]

On Wed, Nov 27, 2019 at 4:01 AM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Mon, 25 Nov 2019 20:25:53 +0100,
> Curtis Malainey wrote:
> >
> > Hello ALSA Devs,
> >
> > I am looking to get some feedback/ideas on a possible change to
> > headset button mapping. Locally we are carrying patches that implement
> > the mappings in the machine driver (which we understand you do not
> > want upstream.) We are looking to see if we can add a new API
> > (something like a sysfs path potentially) to have userspace pass in
> > the mapping, if it chooses to, so the mapping can still be done in the
> > kernel. That way we can carry just the config locally and remove some
> > of the kernel patches we are carrying locally. Thanks.
>
> I guess you're referring to the mapping that is currently done via
> snd_jack_set_key() calls?  If so, an additional sysfs or such
> interface would be handy, and it should be relatively easy.
Yes this is what I was thinking.
>
> But a proper sysfs entry design is another question; it's an array,
> and this can be set for each jack object, so not that trivial.
Agreed, it will likely take some work, but it is good to know you are
open to the idea. I can start looking at some possible designs and
share them here. Hopefully will have them in the next week or two.
>
>
> thanks,
>
> Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Mads Lønsethagen]

On 25.11.2019 20:25, Curtis Malainey wrote:
> Hello ALSA Devs,
> 
> I am looking to get some feedback/ideas on a possible change to
> headset button mapping. Locally we are carrying patches that implement
> the mappings in the machine driver (which we understand you do not
> want upstream.) We are looking to see if we can add a new API
> (something like a sysfs path potentially) to have userspace pass in
> the mapping, if it chooses to, so the mapping can still be done in the
> kernel. That way we can carry just the config locally and remove some
> of the kernel patches we are carrying locally. Thanks.
> 
> Curtis
> 

Sorry for the top posting in my last mail.

I just wondered, do this have anything to do with headphones that has 
physical buttons on the headphone wire itself? E.g the Bose QC25 is a 
pair of headphones that has four buttons on the wire, and as far as I 
can see there's no way of getting those buttons to work in vanilla Linux 
for now, but it works in Android and Windows 10.

I asked about this on this mailing list before[1], because I don't even 
know which component should be responsible for generating button events. 
Should it have anything to do with alsa? Is the button mapping you're 
asking about here about the same thing? Do anyone know how one should go 
about supporting these kind of button events on desktop Linux?

- Mads

[1] 
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-October/157702.html
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Curtis Malainey]

On Thu, Nov 28, 2019 at 1:13 AM Mads Lønsethagen <mads@ab3.no> wrote:

> On 25.11.2019 20:25, Curtis Malainey wrote:
> > Hello ALSA Devs,
> >
> > I am looking to get some feedback/ideas on a possible change to
> > headset button mapping. Locally we are carrying patches that implement
> > the mappings in the machine driver (which we understand you do not
> > want upstream.) We are looking to see if we can add a new API
> > (something like a sysfs path potentially) to have userspace pass in
> > the mapping, if it chooses to, so the mapping can still be done in the
> > kernel. That way we can carry just the config locally and remove some
> > of the kernel patches we are carrying locally. Thanks.
> >
> > Curtis
> >
>
> Hi Mads,

Apologies, apparently my spam filter grabbed your email from me (back to
adjusting the rules.)

> Sorry for the top posting in my last mail.
>
> I just wondered, do this have anything to do with headphones that has
> physical buttons on the headphone wire itself? E.g the Bose QC25 is a
> pair of headphones that has four buttons on the wire, and as far as I
> can see there's no way of getting those buttons to work in vanilla Linux
> for now, but it works in Android and Windows 10.
>

No this is related to ChromeOS device headset button mapping, but hopefully
android will pick this up as well.
Yes, these buttons are the ones I am discussing. Currently in ChromeOS (and
likely in Android as well) we carry patches such as
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1033465/
It appears some have started landing
upstream ae09a4783b9caf9307f303ef039f8297ce0371fe ("ASoC: Intel: Headset
button support in kabylake machine driver") but it would be great if we had
a way for userspace to configure these buttons similar to how we handle
UCMs.

I asked about this on this mailing list before[1], because I don't even
> know which component should be responsible for generating button events.
> Should it have anything to do with alsa? Is the button mapping you're
> asking about here about the same thing? Do anyone know how one should go
> about supporting these kind of button events on desktop Linux?
>
> This project will have to be tied to ALSA in some fashion (as you can see
it is tied to the jack which is an ALSA concept), but I still have to do
the design docs. In theory, this will enable vanilla linux to be configured
for any headset buttons once done.

> - Mads
>
> [1]
>
> https://mailman.alsa-project.org/pipermail/alsa-devel/2019-October/157702.html
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Jaroslav Kysela]

Dne 03. 12. 19 v 21:43 Curtis Malainey napsal(a):
> On Thu, Nov 28, 2019 at 1:13 AM Mads Lønsethagen <mads@ab3.no> wrote:
> 
>> On 25.11.2019 20:25, Curtis Malainey wrote:
>>> Hello ALSA Devs,
>>>
>>> I am looking to get some feedback/ideas on a possible change to
>>> headset button mapping. Locally we are carrying patches that implement
>>> the mappings in the machine driver (which we understand you do not
>>> want upstream.) We are looking to see if we can add a new API
>>> (something like a sysfs path potentially) to have userspace pass in
>>> the mapping, if it chooses to, so the mapping can still be done in the
>>> kernel. That way we can carry just the config locally and remove some
>>> of the kernel patches we are carrying locally. Thanks.
>>>
>>> Curtis
>>>
>>
>> Hi Mads,
> 
> Apologies, apparently my spam filter grabbed your email from me (back to
> adjusting the rules.)
> 
>> Sorry for the top posting in my last mail.
>>
>> I just wondered, do this have anything to do with headphones that has
>> physical buttons on the headphone wire itself? E.g the Bose QC25 is a
>> pair of headphones that has four buttons on the wire, and as far as I
>> can see there's no way of getting those buttons to work in vanilla Linux
>> for now, but it works in Android and Windows 10.
>>
> 
> No this is related to ChromeOS device headset button mapping, but hopefully
> android will pick this up as well.
> Yes, these buttons are the ones I am discussing. Currently in ChromeOS (and
> likely in Android as well) we carry patches such as
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1033465/
> It appears some have started landing
> upstream ae09a4783b9caf9307f303ef039f8297ce0371fe ("ASoC: Intel: Headset
> button support in kabylake machine driver") but it would be great if we had
> a way for userspace to configure these buttons similar to how we handle
> UCMs.

The question why you need to change this settings in the user space. I think 
that the device tree was designed exactly to describe this hw platform 
specific settings. Another possibility is to use the kernel module option to 
configure the settings from the user space. But it's just an idea. You are 
probably looking for an interface which can be used when the driver is running.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Pierre-Louis Bossart]

>> It appears some have started landing
>> upstream ae09a4783b9caf9307f303ef039f8297ce0371fe ("ASoC: Intel: Headset
>> button support in kabylake machine driver") but it would be great if 
>> we had
>> a way for userspace to configure these buttons similar to how we handle
>> UCMs.
> 
> The question why you need to change this settings in the user space. I 
> think that the device tree was designed exactly to describe this hw 
> platform specific settings. Another possibility is to use the kernel 
> module option to configure the settings from the user space. But it's 
> just an idea. You are probably looking for an interface which can be 
> used when the driver is running.

I am also unclear on the ask.
We've cleaned-up all machine drivers so that the mapping is identical, 
except for the cases where the codec inverts the buttons.
Are you saying you do an additional remapping of those buttons in 
userpace? If yes, why not fix the machine driver? The mapping is 
typically based on measured impedance, not really something userspace 
should really know about.
Or is this a case where the ChromeOS kernel has not yet seen the 
upstream patches?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Mads Lønsethagen]

On 03.12.2019 21:43, Curtis Malainey wrote:

> Hi Mads, 
> 
> ...
> 
> This project will have to be tied to ALSA in some fashion (as you can
> see it is tied to the jack which is an ALSA concept), but I still have
> to do the design docs. In theory, this will enable vanilla linux to be
> configured for any headset buttons once done. 
> 

Thank you for replying, it's nice to know about this :)

- Mads
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Headset button mapping in the kernel

[Curtis Malainey]

On Tue, Dec 3, 2019 at 4:34 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
>
>
> >> It appears some have started landing
> >> upstream ae09a4783b9caf9307f303ef039f8297ce0371fe ("ASoC: Intel: Headset
> >> button support in kabylake machine driver") but it would be great if
> >> we had
> >> a way for userspace to configure these buttons similar to how we handle
> >> UCMs.
> >
> > The question why you need to change this settings in the user space. I
> > think that the device tree was designed exactly to describe this hw
> > platform specific settings. Another possibility is to use the kernel
> > module option to configure the settings from the user space. But it's
> > just an idea. You are probably looking for an interface which can be
> > used when the driver is running.
>
> I am also unclear on the ask.
> We've cleaned-up all machine drivers so that the mapping is identical,
> except for the cases where the codec inverts the buttons.
> Are you saying you do an additional remapping of those buttons in
> userpace? If yes, why not fix the machine driver? The mapping is
> typically based on measured impedance, not really something userspace
> should really know about.
This is something we were under the impression upstream did not want.
Dylan can you clarify our stance here? If we can just add the changes
to the kernel then this would be a no-op.
> Or is this a case where the ChromeOS kernel has not yet seen the
> upstream patches?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel