After installing the Ubuntu Linux, the micmute led status is not correct. Users expect that the led is on if the capture is disabled, but with the current kernel, the led is off with the capture disabled.
We tried the old linux kernel like linux-4.15, there is no this issue. It looks like we introduced this issue when switching to the led_cdev.
Cc: stable@vger.kernel.org Signed-off-by: Hui Wang hui.wang@canonical.com --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index daedcc0adc21..09d93dd88713 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4414,6 +4414,7 @@ static void alc233_fixup_lenovo_line2_mic_hotkey(struct hda_codec *codec, { struct alc_spec *spec = codec->spec;
+ spec->micmute_led_polarity = 1; alc_fixup_hp_gpio_led(codec, action, 0, 0x04); if (action == HDA_FIXUP_ACT_PRE_PROBE) { spec->init_amp = ALC_INIT_DEFAULT;
On Mon, 10 Aug 2020 04:16:59 +0200, Hui Wang wrote:
After installing the Ubuntu Linux, the micmute led status is not correct. Users expect that the led is on if the capture is disabled, but with the current kernel, the led is off with the capture disabled.
We tried the old linux kernel like linux-4.15, there is no this issue. It looks like we introduced this issue when switching to the led_cdev.
The behavior can be controlled via "Mic Mute-LED Mode" enum kcontrol. Which value does it have now? If it's "Follow Capture", that's the correct behavior. OTOH, if it's "Follow Mute", the LED polarity is indeed wrong.
thanks,
Takashi
Cc: stable@vger.kernel.org Signed-off-by: Hui Wang hui.wang@canonical.com
sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index daedcc0adc21..09d93dd88713 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4414,6 +4414,7 @@ static void alc233_fixup_lenovo_line2_mic_hotkey(struct hda_codec *codec, { struct alc_spec *spec = codec->spec;
- spec->micmute_led_polarity = 1; alc_fixup_hp_gpio_led(codec, action, 0, 0x04); if (action == HDA_FIXUP_ACT_PRE_PROBE) { spec->init_amp = ALC_INIT_DEFAULT;
-- 2.17.1
On 2020/8/10 下午2:30, Takashi Iwai wrote:
On Mon, 10 Aug 2020 04:16:59 +0200, Hui Wang wrote:
After installing the Ubuntu Linux, the micmute led status is not correct. Users expect that the led is on if the capture is disabled, but with the current kernel, the led is off with the capture disabled.
We tried the old linux kernel like linux-4.15, there is no this issue. It looks like we introduced this issue when switching to the led_cdev.
The behavior can be controlled via "Mic Mute-LED Mode" enum kcontrol. Which value does it have now? If it's "Follow Capture", that's the correct behavior. OTOH, if it's "Follow Mute", the LED polarity is indeed wrong.
It is "Follow Mute", if I change it to "Follow Capture" manually, the led status becomes correct.
Thanks.
thanks,
Takashi
Cc: stable@vger.kernel.org Signed-off-by: Hui Wang hui.wang@canonical.com
sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index daedcc0adc21..09d93dd88713 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4414,6 +4414,7 @@ static void alc233_fixup_lenovo_line2_mic_hotkey(struct hda_codec *codec, { struct alc_spec *spec = codec->spec;
- spec->micmute_led_polarity = 1; alc_fixup_hp_gpio_led(codec, action, 0, 0x04); if (action == HDA_FIXUP_ACT_PRE_PROBE) { spec->init_amp = ALC_INIT_DEFAULT;
-- 2.17.1
On Mon, 10 Aug 2020 08:34:36 +0200, Hui Wang wrote:
On 2020/8/10 下午2:30, Takashi Iwai wrote:
On Mon, 10 Aug 2020 04:16:59 +0200, Hui Wang wrote:
After installing the Ubuntu Linux, the micmute led status is not correct. Users expect that the led is on if the capture is disabled, but with the current kernel, the led is off with the capture disabled.
We tried the old linux kernel like linux-4.15, there is no this issue. It looks like we introduced this issue when switching to the led_cdev.
The behavior can be controlled via "Mic Mute-LED Mode" enum kcontrol. Which value does it have now? If it's "Follow Capture", that's the correct behavior. OTOH, if it's "Follow Mute", the LED polarity is indeed wrong.
It is "Follow Mute", if I change it to "Follow Capture" manually, the led status becomes correct.
OK, thanks for confirmation. Applied now.
Takashi
Hi,
On Aug 10, 2020, at 14:51, Takashi Iwai tiwai@suse.de wrote:
On Mon, 10 Aug 2020 08:34:36 +0200, Hui Wang wrote:
On 2020/8/10 下午2:30, Takashi Iwai wrote:
On Mon, 10 Aug 2020 04:16:59 +0200, Hui Wang wrote:
After installing the Ubuntu Linux, the micmute led status is not correct. Users expect that the led is on if the capture is disabled, but with the current kernel, the led is off with the capture disabled.
We tried the old linux kernel like linux-4.15, there is no this issue. It looks like we introduced this issue when switching to the led_cdev.
The behavior can be controlled via "Mic Mute-LED Mode" enum kcontrol. Which value does it have now? If it's "Follow Capture", that's the correct behavior. OTOH, if it's "Follow Mute", the LED polarity is indeed wrong.
It is "Follow Mute", if I change it to "Follow Capture" manually, the led status becomes correct.
OK, thanks for confirmation. Applied now.
I wonder if it's because how brightness value passed to gpio_mute_led_set() and micmute_led_set():
static int gpio_mute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mute_led_mask, spec->mute_led_polarity, !brightness); return 0; }
static int micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mic_led_mask, spec->micmute_led_polarity, !!brightness); return 0; }
Maybe we should let micmute_led_set() match gpio_mute_led_set() so the micmute polarity can be removed?
Kai-Heng
Takashi
On 2020/8/11 下午4:56, Kai-Heng Feng wrote:
Hi,
On Aug 10, 2020, at 14:51, Takashi Iwai tiwai@suse.de wrote:
On Mon, 10 Aug 2020 08:34:36 +0200, Hui Wang wrote:
On 2020/8/10 下午2:30, Takashi Iwai wrote:
On Mon, 10 Aug 2020 04:16:59 +0200, Hui Wang wrote:
After installing the Ubuntu Linux, the micmute led status is not correct. Users expect that the led is on if the capture is disabled, but with the current kernel, the led is off with the capture disabled.
We tried the old linux kernel like linux-4.15, there is no this issue. It looks like we introduced this issue when switching to the led_cdev.
The behavior can be controlled via "Mic Mute-LED Mode" enum kcontrol. Which value does it have now? If it's "Follow Capture", that's the correct behavior. OTOH, if it's "Follow Mute", the LED polarity is indeed wrong.
It is "Follow Mute", if I change it to "Follow Capture" manually, the led status becomes correct.
OK, thanks for confirmation. Applied now.
I wonder if it's because how brightness value passed to gpio_mute_led_set() and micmute_led_set():
static int gpio_mute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mute_led_mask, spec->mute_led_polarity, !brightness); return 0;}
static int micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mic_led_mask, spec->micmute_led_polarity, !!brightness); return 0;}
Maybe we should let micmute_led_set() match gpio_mute_led_set() so the micmute polarity can be removed?
This will impact many many machines, I don't know if the current code could work correctly or not on other machines.
Thanks,
Hui.
Kai-Heng
Takashi
On Tue, 11 Aug 2020 11:03:55 +0200, Hui Wang wrote:
On 2020/8/11 下午4:56, Kai-Heng Feng wrote:
Hi,
On Aug 10, 2020, at 14:51, Takashi Iwai tiwai@suse.de wrote:
On Mon, 10 Aug 2020 08:34:36 +0200, Hui Wang wrote:
On 2020/8/10 下午2:30, Takashi Iwai wrote:
On Mon, 10 Aug 2020 04:16:59 +0200, Hui Wang wrote:
After installing the Ubuntu Linux, the micmute led status is not correct. Users expect that the led is on if the capture is disabled, but with the current kernel, the led is off with the capture disabled.
We tried the old linux kernel like linux-4.15, there is no this issue. It looks like we introduced this issue when switching to the led_cdev.
The behavior can be controlled via "Mic Mute-LED Mode" enum kcontrol. Which value does it have now? If it's "Follow Capture", that's the correct behavior. OTOH, if it's "Follow Mute", the LED polarity is indeed wrong.
It is "Follow Mute", if I change it to "Follow Capture" manually, the led status becomes correct.
OK, thanks for confirmation. Applied now.
I wonder if it's because how brightness value passed to gpio_mute_led_set() and micmute_led_set():
static int gpio_mute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mute_led_mask, spec->mute_led_polarity, !brightness); return 0;}
static int micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mic_led_mask, spec->micmute_led_polarity, !!brightness); return 0;}
Maybe we should let micmute_led_set() match gpio_mute_led_set() so the micmute polarity can be removed?
This will impact many many machines, I don't know if the current code could work correctly or not on other machines.
True. But we should rather fix this, the current flag is illogical. I forgot about this problem while I also noticed during working on the led cdev conversion.
I guess most of configurations can be verified with hda-emu or such. Let's see...
Takashi
On 2020/8/11 下午5:22, Takashi Iwai wrote:
On Tue, 11 Aug 2020 11:03:55 +0200, Hui Wang wrote:
On 2020/8/11 下午4:56, Kai-Heng Feng wrote:
Hi,
On Aug 10, 2020, at 14:51, Takashi Iwai tiwai@suse.de wrote:
On Mon, 10 Aug 2020 08:34:36 +0200, Hui Wang wrote:
On 2020/8/10 下午2:30, Takashi Iwai wrote:
On Mon, 10 Aug 2020 04:16:59 +0200, Hui Wang wrote: > After installing the Ubuntu Linux, the micmute led status is not > correct. Users expect that the led is on if the capture is disabled, > but with the current kernel, the led is off with the capture disabled. > > We tried the old linux kernel like linux-4.15, there is no this issue. > It looks like we introduced this issue when switching to the led_cdev. The behavior can be controlled via "Mic Mute-LED Mode" enum kcontrol. Which value does it have now? If it's "Follow Capture", that's the correct behavior. OTOH, if it's "Follow Mute", the LED polarity is indeed wrong.
It is "Follow Mute", if I change it to "Follow Capture" manually, the led status becomes correct.
OK, thanks for confirmation. Applied now.
I wonder if it's because how brightness value passed to gpio_mute_led_set() and micmute_led_set():
static int gpio_mute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mute_led_mask, spec->mute_led_polarity, !brightness); return 0;}
static int micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mic_led_mask, spec->micmute_led_polarity, !!brightness); return 0;}
Maybe we should let micmute_led_set() match gpio_mute_led_set() so the micmute polarity can be removed?
This will impact many many machines, I don't know if the current code could work correctly or not on other machines.
True. But we should rather fix this, the current flag is illogical. I forgot about this problem while I also noticed during working on the led cdev conversion.
I guess most of configurations can be verified with hda-emu or such. Let's see...
I just checked, the commit 87dc36482cab (ALSA: hda/realtek - Add LED class support for micmute LED) introduced this issue. In the micmute_led_set(), it set the led with the !!mic_mute.led_value, while before this commit, the driver sets the led with !mic_mute.led_value.
Add with this commit 7cdf8c49b1df (ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev), all micmute led updating will call micmute_led_set(). It impacts alc269_fixup_hp_gpio_led(), alc285_fixup_hp_gpio_led(), alc286_fixup_hp_gpio_led(), alc280_fixup_hp_gpio2_mic_hotkey() and alc233_fixup_lenovo_line2_mic_hotkey()
I think it is safe to change the micmute_led_set() and remove all spec->micmute_led_polarity = 1.
Let me write a patch.
Thanks,
Hui.
.
Takashi
On Tue, 11 Aug 2020 13:55:25 +0200, Hui Wang wrote:
On 2020/8/11 下午5:22, Takashi Iwai wrote:
On Tue, 11 Aug 2020 11:03:55 +0200, Hui Wang wrote:
On 2020/8/11 下午4:56, Kai-Heng Feng wrote:
Hi,
On Aug 10, 2020, at 14:51, Takashi Iwai tiwai@suse.de wrote:
On Mon, 10 Aug 2020 08:34:36 +0200, Hui Wang wrote:
On 2020/8/10 下午2:30, Takashi Iwai wrote: > On Mon, 10 Aug 2020 04:16:59 +0200, > Hui Wang wrote: >> After installing the Ubuntu Linux, the micmute led status is not >> correct. Users expect that the led is on if the capture is disabled, >> but with the current kernel, the led is off with the capture disabled. >> >> We tried the old linux kernel like linux-4.15, there is no this issue. >> It looks like we introduced this issue when switching to the led_cdev. > The behavior can be controlled via "Mic Mute-LED Mode" enum kcontrol. > Which value does it have now? If it's "Follow Capture", that's the > correct behavior. OTOH, if it's "Follow Mute", the LED polarity is > indeed wrong. It is "Follow Mute", if I change it to "Follow Capture" manually, the led status becomes correct.
OK, thanks for confirmation. Applied now.
I wonder if it's because how brightness value passed to gpio_mute_led_set() and micmute_led_set():
static int gpio_mute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mute_led_mask, spec->mute_led_polarity, !brightness); return 0;}
static int micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct hda_codec *codec = dev_to_hda_codec(led_cdev->dev->parent); struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mic_led_mask, spec->micmute_led_polarity, !!brightness); return 0;}
Maybe we should let micmute_led_set() match gpio_mute_led_set() so the micmute polarity can be removed?
This will impact many many machines, I don't know if the current code could work correctly or not on other machines.
True. But we should rather fix this, the current flag is illogical. I forgot about this problem while I also noticed during working on the led cdev conversion.
I guess most of configurations can be verified with hda-emu or such. Let's see...
I just checked, the commit 87dc36482cab (ALSA: hda/realtek - Add LED class support for micmute LED) introduced this issue. In the micmute_led_set(), it set the led with the !!mic_mute.led_value, while before this commit, the driver sets the led with !mic_mute.led_value.
Add with this commit 7cdf8c49b1df (ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev), all micmute led updating will call micmute_led_set(). It impacts alc269_fixup_hp_gpio_led(), alc285_fixup_hp_gpio_led(), alc286_fixup_hp_gpio_led(), alc280_fixup_hp_gpio2_mic_hotkey() and alc233_fixup_lenovo_line2_mic_hotkey()
I think it is safe to change the micmute_led_set() and remove all spec->micmute_led_polarity = 1.
Let me write a patch.
Great, thanks for spotting out.
Takashi
linux-stable-mirror@lists.linaro.org
-
Hui Wang -
Kai-Heng Feng -
Takashi Iwai