diff mbox

[1/2] ALSA: hda - Add mic mute hotkey quirk for Lenovo ThinkCentre AIO

Message ID 1450928798-31191-1-git-send-email-hui.wang@canonical.com (mailing list archive)
State New, archived
Headers show

Commit Message

Hui Wang Dec. 24, 2015, 3:46 a.m. UTC 
From: Kailang <kailang@realtek.com>

The Lenovo ThinkCenter AIO uses Line2 (NID 0x1b) to implement the
micmute hotkey, here we register an input device and use Line2 unsol
event to collect the hotkey pressing or releasing.

In the meanwhile, the micmute led is controlled by GPIO2, so we
use an existing function alc_fixup_gpio_mic_mute_hook() to control
the led.

Cc: <stable@vger.kernel.org>
Signed-off-by: Kailang <kailang@realtek.com>
---
 sound/pci/hda/patch_realtek.c | 59 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

Comments

Takashi Iwai Dec. 24, 2015, 6:44 a.m. UTC | #1 
On Thu, 24 Dec 2015 04:46:37 +0100,
Hui Wang wrote:
> 
> From: Kailang <kailang@realtek.com>
> 
> The Lenovo ThinkCenter AIO uses Line2 (NID 0x1b) to implement the
> micmute hotkey, here we register an input device and use Line2 unsol
> event to collect the hotkey pressing or releasing.
> 
> In the meanwhile, the micmute led is controlled by GPIO2, so we
> use an existing function alc_fixup_gpio_mic_mute_hook() to control
> the led.
> 
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Kailang <kailang@realtek.com>

Is it mandatory expose this as a key event?  I mean, wouldn't it
suffice just toggle the mic mute by the driver itself?  User-space
will get the notification by the mixer status change in anyway.


Takashi
Takashi Iwai Dec. 24, 2015, 7:45 a.m. UTC | #2 
On Thu, 24 Dec 2015 07:44:22 +0100,
Takashi Iwai wrote:
> 
> On Thu, 24 Dec 2015 04:46:37 +0100,
> Hui Wang wrote:
> > 
> > From: Kailang <kailang@realtek.com>
> > 
> > The Lenovo ThinkCenter AIO uses Line2 (NID 0x1b) to implement the
> > micmute hotkey, here we register an input device and use Line2 unsol
> > event to collect the hotkey pressing or releasing.
> > 
> > In the meanwhile, the micmute led is controlled by GPIO2, so we
> > use an existing function alc_fixup_gpio_mic_mute_hook() to control
> > the led.
> > 
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Kailang <kailang@realtek.com>
> 
> Is it mandatory expose this as a key event?  I mean, wouldn't it
> suffice just toggle the mic mute by the driver itself?  User-space
> will get the notification by the mixer status change in anyway.

More specifically, what I thought of is symmetry: if a mute switch is
implemented in a hard-coded way, we may follow the similar logic for
the mic mute, too.  OTOH, if a mute switch is handled in an open way
using the normal key code, we should follow that for the mic mute,
too, like this patch provides.


Takashi
Hui Wang Dec. 24, 2015, 9:39 a.m. UTC | #3 
On 12/24/2015 03:45 PM, Takashi Iwai wrote:
> On Thu, 24 Dec 2015 07:44:22 +0100,
> Takashi Iwai wrote:
>> On Thu, 24 Dec 2015 04:46:37 +0100,
>> Hui Wang wrote:
>>> From: Kailang <kailang@realtek.com>
>>>
>>> The Lenovo ThinkCenter AIO uses Line2 (NID 0x1b) to implement the
>>> micmute hotkey, here we register an input device and use Line2 unsol
>>> event to collect the hotkey pressing or releasing.
>>>
>>> In the meanwhile, the micmute led is controlled by GPIO2, so we
>>> use an existing function alc_fixup_gpio_mic_mute_hook() to control
>>> the led.
>>>
>>> Cc: <stable@vger.kernel.org>
>>> Signed-off-by: Kailang <kailang@realtek.com>
>> Is it mandatory expose this as a key event?  I mean, wouldn't it
>> suffice just toggle the mic mute by the driver itself?  User-space
>> will get the notification by the mixer status change in anyway.
We implement it to be an input device just because we need to meet the 
X11 requirement, the X11 layer capture the key event instead of mixer 
status. After the X11 get the keycode, It will set microphone to mute 
from userspace, it is easy to do that by the driver itself, but X11 also 
need to know the status change, since the X11 will show up an micmute 
OSD according to status change, and needs to save the finial status 
before reboot or poweroff. If we don't implement the input device, we 
have to modify the X11 layer.


> More specifically, what I thought of is symmetry: if a mute switch is
> implemented in a hard-coded way, we may follow the similar logic for
> the mic mute, too.  OTOH, if a mute switch is handled in an open way
> using the normal key code, we should follow that for the mic mute,
> too, like this patch provides.
After the X11 get the keycode, It will do some change for this keycode 
((8bit)XF11keycode=keycode+0x10).  The keycode of KEY_MUTE is 113, it is 
ok to do the change, but the keycode of KEY_MICMUTE is 248, It will 
overflow if add 0x10 to it, so the X11 developer choose another keycode 
to be the micmute, the keycode they chose is KEY_F20.

If you search XF86AudioMicMute in the xkeyboard-config-2.14/symbols/inet 
(in the 2.14 tarball file) of 
http://freedesktop.org/wiki/Software/XKeyboardConfig/, you will find the 
keycode map to X11 micmute is KEY_F20 instead of KEY_MICMUTE.

>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
Takashi Iwai Dec. 24, 2015, 1:03 p.m. UTC | #4 
On Thu, 24 Dec 2015 10:39:48 +0100,
Hui Wang wrote:
> 
> On 12/24/2015 03:45 PM, Takashi Iwai wrote:
> > On Thu, 24 Dec 2015 07:44:22 +0100,
> > Takashi Iwai wrote:
> >> On Thu, 24 Dec 2015 04:46:37 +0100,
> >> Hui Wang wrote:
> >>> From: Kailang <kailang@realtek.com>
> >>>
> >>> The Lenovo ThinkCenter AIO uses Line2 (NID 0x1b) to implement the
> >>> micmute hotkey, here we register an input device and use Line2 unsol
> >>> event to collect the hotkey pressing or releasing.
> >>>
> >>> In the meanwhile, the micmute led is controlled by GPIO2, so we
> >>> use an existing function alc_fixup_gpio_mic_mute_hook() to control
> >>> the led.
> >>>
> >>> Cc: <stable@vger.kernel.org>
> >>> Signed-off-by: Kailang <kailang@realtek.com>
> >> Is it mandatory expose this as a key event?  I mean, wouldn't it
> >> suffice just toggle the mic mute by the driver itself?  User-space
> >> will get the notification by the mixer status change in anyway.
> We implement it to be an input device just because we need to meet the 
> X11 requirement, the X11 layer capture the key event instead of mixer 
> status. After the X11 get the keycode, It will set microphone to mute 
> from userspace, it is easy to do that by the driver itself, but X11 also 
> need to know the status change, since the X11 will show up an micmute 
> OSD according to status change, and needs to save the finial status 
> before reboot or poweroff. If we don't implement the input device, we 
> have to modify the X11 layer.

Does the mute button this machine work in that way, too?


Takashi
Hui Wang Dec. 25, 2015, 2:19 a.m. UTC | #5 
On 12/24/2015 09:03 PM, Takashi Iwai wrote:
> On Thu, 24 Dec 2015 10:39:48 +0100,
> Hui Wang wrote:
>> On 12/24/2015 03:45 PM, Takashi Iwai wrote:
>>> On Thu, 24 Dec 2015 07:44:22 +0100,
>>> Takashi Iwai wrote:
>>>> On Thu, 24 Dec 2015 04:46:37 +0100,
>>>> Hui Wang wrote:
>>>>> From: Kailang <kailang@realtek.com>
>>>>>
>>>>> The Lenovo ThinkCenter AIO uses Line2 (NID 0x1b) to implement the
>>>>> micmute hotkey, here we register an input device and use Line2 unsol
>>>>> event to collect the hotkey pressing or releasing.
>>>>>
>>>>> In the meanwhile, the micmute led is controlled by GPIO2, so we
>>>>> use an existing function alc_fixup_gpio_mic_mute_hook() to control
>>>>> the led.
>>>>>
>>>>> Cc: <stable@vger.kernel.org>
>>>>> Signed-off-by: Kailang <kailang@realtek.com>
>>>> Is it mandatory expose this as a key event?  I mean, wouldn't it
>>>> suffice just toggle the mic mute by the driver itself?  User-space
>>>> will get the notification by the mixer status change in anyway.
>> We implement it to be an input device just because we need to meet the
>> X11 requirement, the X11 layer capture the key event instead of mixer
>> status. After the X11 get the keycode, It will set microphone to mute
>> from userspace, it is easy to do that by the driver itself, but X11 also
>> need to know the status change, since the X11 will show up an micmute
>> OSD according to status change, and needs to save the finial status
>> before reboot or poweroff. If we don't implement the input device, we
>> have to modify the X11 layer.
> Does the mute button this machine work in that way, too?
There is no mute button on this AIO machine, there is only a micmute 
button on the right side of the monitor.


>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
diff mbox

Patch

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index fe96428..8adff4f 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3528,6 +3528,59 @@  static void alc280_fixup_hp_gpio2_mic_hotkey(struct hda_codec *codec,
 	}
 }
 
+static void alc233_fixup_lenovo_line2_mic_hotkey(struct hda_codec *codec,
+					     const struct hda_fixup *fix, int action)
+{
+	/* Line2 = mic mute hotkey
+	   GPIO2 = mic mute LED */
+	static const struct hda_verb gpio_init[] = {
+		{ 0x01, AC_VERB_SET_GPIO_MASK, 0x04 },
+		{ 0x01, AC_VERB_SET_GPIO_DIRECTION, 0x04 },
+		{}
+	};
+
+	struct alc_spec *spec = codec->spec;
+
+	if (action == HDA_FIXUP_ACT_PRE_PROBE) {
+		spec->kb_dev = input_allocate_device();
+		if (!spec->kb_dev) {
+			codec_err(codec, "Out of memory (input_allocate_device)\n");
+			return;
+		}
+		spec->kb_dev->name = "Microphone Mute Button";
+		spec->kb_dev->evbit[0] = BIT_MASK(EV_KEY);
+		spec->kb_dev->keybit[BIT_WORD(KEY_MICMUTE)] = BIT_MASK(KEY_MICMUTE);
+		if (input_register_device(spec->kb_dev)) {
+			codec_err(codec, "input_register_device failed\n");
+			input_free_device(spec->kb_dev);
+			spec->kb_dev = NULL;
+			return;
+		}
+
+		snd_hda_add_verbs(codec, gpio_init);
+		snd_hda_jack_detect_enable_callback(codec, 0x1b,
+						    gpio2_mic_hotkey_event);
+
+		spec->gen.cap_sync_hook = alc_fixup_gpio_mic_mute_hook;
+		spec->gpio_led = 0;
+		spec->mute_led_polarity = 0;
+		spec->gpio_mic_led_mask = 0x04;
+		return;
+	}
+
+	if (!spec->kb_dev)
+		return;
+
+	switch (action) {
+	case HDA_FIXUP_ACT_PROBE:
+		spec->init_amp = ALC_INIT_DEFAULT;
+		break;
+	case HDA_FIXUP_ACT_FREE:
+		input_unregister_device(spec->kb_dev);
+		spec->kb_dev = NULL;
+	}
+}
+
 static void alc269_fixup_hp_line1_mic1_led(struct hda_codec *codec,
 				const struct hda_fixup *fix, int action)
 {
@@ -4628,6 +4681,7 @@  enum {
 	ALC275_FIXUP_DELL_XPS,
 	ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE,
 	ALC293_FIXUP_LENOVO_SPK_NOISE,
+	ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -5237,6 +5291,10 @@  static const struct hda_fixup alc269_fixups[] = {
 		.chained = true,
 		.chain_id = ALC269_FIXUP_THINKPAD_ACPI
 	},
+	[ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc233_fixup_lenovo_line2_mic_hotkey,
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -5386,6 +5444,7 @@  static const struct snd_pci_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x2223, "ThinkPad T550", ALC292_FIXUP_TPT440_DOCK),
 	SND_PCI_QUIRK(0x17aa, 0x2226, "ThinkPad X250", ALC292_FIXUP_TPT440_DOCK),
 	SND_PCI_QUIRK(0x17aa, 0x2233, "Thinkpad", ALC293_FIXUP_LENOVO_SPK_NOISE),
+	SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY),
 	SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC),
 	SND_PCI_QUIRK(0x17aa, 0x3978, "IdeaPad Y410P", ALC269_FIXUP_NO_SHUTUP),
 	SND_PCI_QUIRK(0x17aa, 0x5013, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),