[alsa-devel] Headset button mapping in the kernel

[Curtis Malainey]

On Thu, Nov 28, 2019 at 1:13 AM Mads Lønsethagen <mads at 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
>