[PATCH 1/2] ASoC: rt711: remap buttons

[PATCH 1/2] ASoC: rt711: remap buttons

[shumingf]

From: Shuming Fan <shumingf@realtek.com>

This patch uses the same mapping as the machine driver:
BTN_0 : KEY_PLAYPAUSE
BTN_1 : KEY_VOICECOMMAND
BTN_2 : KEY_VOLUMEUP
BTN_3 : KEY_VOLUMEDOWN

Signed-off-by: Shuming Fan <shumingf@realtek.com>
---
 sound/soc/codecs/rt711.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/rt711.c b/sound/soc/codecs/rt711.c
index 9f5b2dc16c54..c3a82b462a93 100644
--- a/sound/soc/codecs/rt711.c
+++ b/sound/soc/codecs/rt711.c
@@ -154,26 +154,26 @@ static unsigned int rt711_button_detect(struct rt711_priv *rt711)
 	case 0x0200:
 	case 0x0100:
 	case 0x0080:
-		btn_type |= SND_JACK_BTN_0;
+		btn_type |= SND_JACK_BTN_2;
 		break;
 	case 0x0001:
-		btn_type |= SND_JACK_BTN_3;
+		btn_type |= SND_JACK_BTN_1;
 		break;
 	}
 	switch (val81) {
 	case 0x8000:
 	case 0x4000:
 	case 0x2000:
-		btn_type |= SND_JACK_BTN_1;
+		btn_type |= SND_JACK_BTN_0;
 		break;
 	case 0x1000:
 	case 0x0800:
 	case 0x0400:
-		btn_type |= SND_JACK_BTN_2;
+		btn_type |= SND_JACK_BTN_3;
 		break;
 	case 0x0200:
 	case 0x0100:
-		btn_type |= SND_JACK_BTN_3;
+		btn_type |= SND_JACK_BTN_1;
 		break;
 	}
 read_error:
-- 
2.31.1

Re: [PATCH 1/2] ASoC: rt711: remap buttons

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Thu, Jun 17, 2021 at 05:08:09PM +0800, shumingf@realtek.com wrote:
> From: Shuming Fan <shumingf@realtek.com>
> 
> This patch uses the same mapping as the machine driver:
> BTN_0 : KEY_PLAYPAUSE
> BTN_1 : KEY_VOICECOMMAND
> BTN_2 : KEY_VOLUMEUP
> BTN_3 : KEY_VOLUMEDOWN

Which machine driver?  Can't there be multiple machine drivers, and if
they're already overriding things why do this?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] ASoC: rt711: remap buttons

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Thu, Jun 17, 2021 at 01:19:05PM +0000, Shuming [范書銘] wrote:

> > > This patch uses the same mapping as the machine driver:
> > > BTN_0 : KEY_PLAYPAUSE
> > > BTN_1 : KEY_VOICECOMMAND
> > > BTN_2 : KEY_VOLUMEUP
> > > BTN_3 : KEY_VOLUMEDOWN

> > Which machine driver?  Can't there be multiple machine drivers, and if
> > they're already overriding things why do this?

> The rt711 codec is designed in the Intel platform only for now.

I'm sure your sales team would be happy to change that!

> The machine driver is 'sof_sdw.c' that resides under sound/soc/intel/boards.
> It seems Intel uses the same mapping in all other Intel machine drivers.
> Please check the commit as below.
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=1f64a08bd5a9a218deb37c03c1e98e9567379698

Sure, but if the machine drivers for these platforms already do the
right thing why change the CODEC driver?

> Hi Sathya,
> Do you know why the m/c driver uses this mapping?

I'd guess it's just because that's the standard set of headphone buttons
that Intel uses for their platforms.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] ASoC: rt711: remap buttons

[Pierre-Louis Bossart]

On 6/17/21 8:27 AM, Mark Brown wrote:
> On Thu, Jun 17, 2021 at 01:19:05PM +0000, Shuming [范書銘] wrote:
> 
>>>> This patch uses the same mapping as the machine driver:
>>>> BTN_0 : KEY_PLAYPAUSE
>>>> BTN_1 : KEY_VOICECOMMAND
>>>> BTN_2 : KEY_VOLUMEUP
>>>> BTN_3 : KEY_VOLUMEDOWN
> 
>>> Which machine driver?  Can't there be multiple machine drivers, and if
>>> they're already overriding things why do this?
> 
>> The rt711 codec is designed in the Intel platform only for now.
> 
> I'm sure your sales team would be happy to change that!
> 
>> The machine driver is 'sof_sdw.c' that resides under sound/soc/intel/boards.
>> It seems Intel uses the same mapping in all other Intel machine drivers.
>> Please check the commit as below.
>> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=1f64a08bd5a9a218deb37c03c1e98e9567379698
> 
> Sure, but if the machine drivers for these platforms already do the
> right thing why change the CODEC driver?
> 
>> Hi Sathya,
>> Do you know why the m/c driver uses this mapping?
> 
> I'd guess it's just because that's the standard set of headphone buttons
> that Intel uses for their platforms.

Intel has no specific requirement, we just follow what the Google 4-button description says [1]

That said, I can't recall why half of the machine drivers follow one pattern and the other half a different one.

Same as spec:
sof_da7219_max98373.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);

sof_cs42l42.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);

swap wrt. spec:
sof_sdw_rt711.c:        snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);

kbl_rt5663_max98927.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);

Brent, Curtis, Jimmy, can you comment on the order?


[1] https://source.android.com/devices/accessories/headset/plug-headset-spec#control-function_mapping




 

Re: [PATCH 1/2] ASoC: rt711: remap buttons

[Curtis Malainey]

On Thu, Jun 17, 2021 at 7:23 AM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
>
> On 6/17/21 8:27 AM, Mark Brown wrote:
> > On Thu, Jun 17, 2021 at 01:19:05PM +0000, Shuming [范書銘] wrote:
> >
> >>>> This patch uses the same mapping as the machine driver:
> >>>> BTN_0 : KEY_PLAYPAUSE
> >>>> BTN_1 : KEY_VOICECOMMAND
> >>>> BTN_2 : KEY_VOLUMEUP
> >>>> BTN_3 : KEY_VOLUMEDOWN
> >
> >>> Which machine driver?  Can't there be multiple machine drivers, and if
> >>> they're already overriding things why do this?
> >
> >> The rt711 codec is designed in the Intel platform only for now.
> >
> > I'm sure your sales team would be happy to change that!
> >
> >> The machine driver is 'sof_sdw.c' that resides under sound/soc/intel/boards.
> >> It seems Intel uses the same mapping in all other Intel machine drivers.
> >> Please check the commit as below.
> >> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=1f64a08bd5a9a218deb37c03c1e98e9567379698
> >
> > Sure, but if the machine drivers for these platforms already do the
> > right thing why change the CODEC driver?
> >
> >> Hi Sathya,
> >> Do you know why the m/c driver uses this mapping?
> >
> > I'd guess it's just because that's the standard set of headphone buttons
> > that Intel uses for their platforms.
>
> Intel has no specific requirement, we just follow what the Google 4-button description says [1]
>
> That said, I can't recall why half of the machine drivers follow one pattern and the other half a different one.
>
> Same as spec:
> sof_da7219_max98373.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
> sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
> sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);
>
> sof_cs42l42.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
> sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
> sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);
>
> swap wrt. spec:
> sof_sdw_rt711.c:        snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
> sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
> sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
>
> kbl_rt5663_max98927.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
> kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
> kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
>
> Brent, Curtis, Jimmy, can you comment on the order?

Sorry for the late reply, I couldn't figure out why this slipped by my
email filter, I guess I should look closer next time. Soraka has been
checked (kbl_rt5663_max98927) and yes the mapping does appear to be
incorrect, volume up key returns voice command in evtest. Sathya will
have to check the headset button mapping, on rt711 but my guess is it
is also incorrect.

>
>
> [1] https://source.android.com/devices/accessories/headset/plug-headset-spec#control-function_mapping
>
>
>
>
>

RE: [PATCH 1/2] ASoC: rt711: remap buttons

[Lu, Brent]

> 
> Intel has no specific requirement, we just follow what the Google 4-button
> description says [1]
> 
> That said, I can't recall why half of the machine drivers follow one pattern and
> the other half a different one.
> 
> Same as spec:
> sof_da7219_max98373.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0,
> KEY_PLAYPAUSE);
> sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1,
> KEY_VOLUMEUP);
> sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2,
> KEY_VOLUMEDOWN);
> sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3,
> KEY_VOICECOMMAND);
> 
> sof_cs42l42.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0,
> KEY_PLAYPAUSE);
> sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1,
> KEY_VOLUMEUP);
> sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2,
> KEY_VOLUMEDOWN);
> sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3,
> KEY_VOICECOMMAND);
> 
> swap wrt. spec:
> sof_sdw_rt711.c:        snd_jack_set_key(jack->jack, SND_JACK_BTN_0,
> KEY_PLAYPAUSE);
> sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_1,
> KEY_VOICECOMMAND);
> sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_2,
> KEY_VOLUMEUP);
> sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_3,
> KEY_VOLUMEDOWN);
> 
> kbl_rt5663_max98927.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0,
> KEY_PLAYPAUSE);
> kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1,
> KEY_VOICECOMMAND);
> kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2,
> KEY_VOLUMEUP);
> kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3,
> KEY_VOLUMEDOWN);
> 
> Brent, Curtis, Jimmy, can you comment on the order?
> 
> 
> [1] https://source.android.com/devices/accessories/headset/plug-headset-
> spec#control-function_mapping
> 
Hi Pierre,

I just shared the link [1] with ODM and codec vendor to double check the 
mapping is following the requirement.

Regards,
Brent

Re: [PATCH 1/2] ASoC: rt711: remap buttons

[Curtis Malainey]

> > Intel has no specific requirement, we just follow what the Google 4-button description says [1]
> >
> > That said, I can't recall why half of the machine drivers follow one pattern and the other half a different one.
> >
> > Same as spec:
> > sof_da7219_max98373.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> > sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
> > sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
> > sof_da7219_max98373.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);
> >
> > sof_cs42l42.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> > sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
> > sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
> > sof_cs42l42.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);
> >
> > swap wrt. spec:
> > sof_sdw_rt711.c:        snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> > sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
> > sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
> > sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
> >
> > kbl_rt5663_max98927.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> > kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
> > kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
> > kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
> >
> > Brent, Curtis, Jimmy, can you comment on the order?
>
> Sorry for the late reply, I couldn't figure out why this slipped by my
> email filter, I guess I should look closer next time. Soraka has been
> checked (kbl_rt5663_max98927) and yes the mapping does appear to be
> incorrect, volume up key returns voice command in evtest. Sathya will
> have to check the headset button mapping, on rt711 but my guess is it
> is also incorrect.

I stand corrected, misread the datasheet. So rt711 and rt5663 are
correct based on datasheet specs but when grabbing an off the shelf
headphone they did not work with the volume up. Hmm, I wonder if this
split is "what usually works" and "what is correct."

RE: [PATCH 1/2] ASoC: rt711: remap buttons

[Shuming [范書銘]]

> > >
> > > swap wrt. spec:
> > > sof_sdw_rt711.c:        snd_jack_set_key(jack->jack, SND_JACK_BTN_0,
> KEY_PLAYPAUSE);
> > > sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_1,
> KEY_VOICECOMMAND);
> > > sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_2,
> KEY_VOLUMEUP);
> > > sof_sdw_rt711.c-        snd_jack_set_key(jack->jack, SND_JACK_BTN_3,
> KEY_VOLUMEDOWN);
> > >
> > > kbl_rt5663_max98927.c:  snd_jack_set_key(jack->jack, SND_JACK_BTN_0,
> > > KEY_PLAYPAUSE);
> > > kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_1,
> > > KEY_VOICECOMMAND);
> > > kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_2,
> > > KEY_VOLUMEUP);
> > > kbl_rt5663_max98927.c-  snd_jack_set_key(jack->jack, SND_JACK_BTN_3,
> > > KEY_VOLUMEDOWN);
> > >
> > > Brent, Curtis, Jimmy, can you comment on the order?
> >
> > Sorry for the late reply, I couldn't figure out why this slipped by my
> > email filter, I guess I should look closer next time. Soraka has been
> > checked (kbl_rt5663_max98927) and yes the mapping does appear to be
> > incorrect, volume up key returns voice command in evtest. Sathya will
> > have to check the headset button mapping, on rt711 but my guess is it
> > is also incorrect.
> 
> I stand corrected, misread the datasheet. So rt711 and rt5663 are correct
> based on datasheet specs but when grabbing an off the shelf headphone they
> did not work with the volume up. Hmm, I wonder if this split is "what usually
> works" and "what is correct."

Thanks for your reply, Curtis.
This patch just changes the mapping to let the button function work properly.

Hi Mark,
Do I need to resend the patch? Or any comments?

> ------Please consider the environment before printing this e-mail.

Re: [PATCH 1/2] ASoC: rt711: remap buttons

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Wed, Jun 30, 2021 at 06:01:52AM +0000, Shuming [范書銘] wrote:

> Do I need to resend the patch? Or any comments?

None of this has answered my original question - to repeat why would we
change the defaults in the CODEC driver given that the machines can
already set what they want anyway and apparently are already doing so?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]