See https://ask.fedoraproject.org/t/linux-5-19-4-200-fc36-x86-64-cause-problem-with-microphone-led-on-thinkpad-x1-carbon-gen-9/26102 for details. I believe this is a bug in the kernel. I have the same problem with kernel-5.19.9-100.fc35.x86_64
I've updated to 5.19.14-100.fc35.x86_64 to see if ti fixes the problem. It does not.
Kernel version: 6.0.8-200.fc36.x86_64 The problem is still here.
I have the same problem. Kernel version: 5.19.14-100.fc35.x86_64
Multiple users on ask.fp.o are affected by this, multiple of my colleagues are affected by this and I think that Lenovo Thinkpad X1 Carbon gen. 9 is quite a popular machine. I opened this Bugzilla more than a month ago, and I've even emailed the kernel maintainers. I propose this as a prioritized bug, because I have no idea how else got some attention from somebody who would be able to fix this.
(In reply to Miro Hrončok from comment #4) > Multiple users on ask.fp.o are affected by this, multiple of my colleagues > are affected by this and I think that Lenovo Thinkpad X1 Carbon gen. 9 is > quite a popular machine. > > I opened this Bugzilla more than a month ago, and I've even emailed the > kernel maintainers. I propose this as a prioritized bug, because I have no > idea how else got some attention from somebody who would be able to fix this. I am aware of the issue, though the dup bug 2126878 on it said it was fixed with the latest 6.0 kernel, so you might give 6.0.10 a try. You did not "email the kernel maintainers", I have no email from you on this subject, and I am the only Fedora kernel maintainer. I also do not see one on the fedora kernel list. No, it won't be a prioritized bug. The prioritized bug concept doesn't particularly work for kernel. RHEL has dozens of kernel engineers, and specific ones dedicated to every subsystem or driver enabled. Fedora has me. If it is not getting fixed quickly enough for your liking, upstream is the venue to get a fix made. I am happy to back port upstream fixes that stable has not picked up yet. While I would love to be able to fix every bug, it is not something I have the time or capacity to do. A bug regarding an LED display is fairly low priority compared to actual crashes, graphics issues, etc.
Thanks for the reply. Will definitively give 6.0.10 a try. I've emailed kernel-maint cca week ago. It is not that it's not fixed fast enough for my liking, it is that it seemed nobody is on the other side of this bugzilla, which is quite frustrating. I do recognize that you don't have the ability to fix every bug.
Linux 6.0.10-100.fc35.x86_64 does not fix this.
(In reply to Miro Hrončok from comment #6) > Thanks for the reply. Will definitively give 6.0.10 a try. > > I've emailed kernel-maint cca week ago. Interesting. I am not sure how that address works outside of a bugzilla construct, it does not come to me though. > > It is not that it's not fixed fast enough for my liking, it is that it > seemed nobody is on the other side of this bugzilla, which is quite > frustrating. I do recognize that you don't have the ability to fix every bug. Yes, almost every kernel bug is treated this way. I do read every comment on every bug, but I do not take the time to comment unless I specifically need more information on something. I just do not have the time to do so.
I wasn't aware of this issue but can reproduce on my system (in my case it's working with 5.17.5-300 but broken in 5.19.6-200; I haven't tried the very latest kernel yet). I'll see if I can track down when it broke. Mark
In today's Prioritized Bugs meeting, we agreed to accept this as it impacts an important laptop model for our community. Mark Pearson at Lenovo can reproduce and is investigating. https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-30/fedora_prioritized_bugs_and_issues.2022-11-30-15.01.log.html#l-63
Looks like this commit is the problem: 9b014266ef8ad0159b39920a752f191bcd6f356c is the first bad commit commit 9b014266ef8ad0159b39920a752f191bcd6f356c Author: Jaroslav Kysela <perex> Date: Tue Mar 29 14:00:39 2022 +0200 ASoC: SOF: topology: use new sound control LED layer Use the new sound control LED layer instead the direct ledtrig_audio_set() call - see 22d8de62f11b ("ALSA: control - add generic LED trigger module as the new control layer"). Signed-off-by: Jaroslav Kysela <perex> Cc: Bard Liao <yung-chuan.liao.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan.com> Link: https://lore.kernel.org/r/20220329120039.2394138-1-perex@perex.cz Signed-off-by: Mark Brown <broonie> sound/soc/sof/control.c | 33 --------------------------------- sound/soc/sof/sof-priv.h | 1 + sound/soc/sof/topology.c | 16 ++++++++++++++++ 3 files changed, 17 insertions(+), 33 deletions(-) Jaroslav - I'll need your help understanding how to fix this. I raised upstream ticket https://github.com/thesofproject/linux/issues/4065 as it looks like this impacts multiple Intel platforms
To make Mic LED work, you need to mute also the analog input (external jack) in the mixer by default. The SOF and HDA drivers registers the Mic LED controls and the logic is to turn the LED on when both inputs are off. The problem is that the SOF driver does not communicate with the HDA driver to avoid attaching the analog capture switch to the sound ctl-led (mic) for those platforms. But personally, I don't think that it's a wrong use case to turn LED only when all notebook inputs are off. Also, you can remove the HDA control from the sound ctl-led using sysfs: echo "Capture Switch" > /sys/class/sound/ctl-led/mic/card0/detach Note that you should identify the SOF/HDA card number at first (cat /proc/asound/cards). Note2: The previous kernel behaviour (without the mentioned patch) was not correct either - both SOF / HDA drivers controlled the Mic LED independently, so the state sync was unpredictable (although users probably didn't notice it so much - retrigger).
Thanks Jaroslav, I can confirm that both disabling the Capture input from alsamixer, and removing it using sysfs method, mean the LED works again. What is the correct way to fix this - I think this is going to impact a lot of systems out there isn't it? Effectively anything with an audio jack (unless I've misunderstood it). I appreciate it is now more correct...but it's still confusing for users. I think we're able to detect if something is plugged into the audio jack. If that is true shouldn't the input jack be either ignored or treated as disabled by default - and only enabled once something is plugged in (not sure if we're able to tell the difference between a headphone and a microphone). Mark
Sorry - one more thought...the Mute button should be muting all inputs shouldn't it? Is there a reason it's not putting the external jack?
If I'm not wrong, the mute button should be muting only the input selected by the user.
FWIW the mute button can do whatever. In my case, it runs a shell script that essentially does: MIC=alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_6__source if [[ "$(pactl get-source-mute $MIC)" == "Mute: no" ]]; then pactl set-source-mute $MIC yes else pactl set-source-mute $MIC no fi
That's very cool; but from my selfish point of view I want Linux to work for users out of the box without doing clever scripting tweaks. If a kernel update has broken that functionality I'd argue the kernel patch is wrong I think the 'new' implementation with the sof topology breaks functionality even if it seems more correct. I'm just not sure where to fix it. Jaroslav - I did raise the ticket on the sof forum but maybe that's the wrong place for this? This issue is looking non-trivial to solve, so in my opinion the kernel patch should be reverted until it is able to operate correctly. I appreciate it is technically correct - but functionally it's wrong (and I believe we a leading rule for kernel updates is to avoid breaking user space). Mark
I don't like the revert idea. The revert does not fix situation / "Mute DMic" -> "Unmute analog jack input" -> LED is off / for the old kernels. The fix can be easy with adding this rule to the UCM config: diff --git a/ucm2/Intel/sof-hda-dsp/sof-hda-dsp.conf b/ucm2/Intel/sof-hda-dsp/sof-hda-dsp.conf dindex e6a8a15..61645f2 100644 --- a/ucm2/Intel/sof-hda-dsp/sof-hda-dsp.conf +++ b/ucm2/Intel/sof-hda-dsp/sof-hda-dsp.conf @@ -9,7 +9,12 @@ If.devdmic { Haystack "${CardComponents}" Needle "cfg-dmics:" } - True.Define.DeviceDmic "Mic1" + True { + Define.DeviceDmic "Mic1" + FixedBootSequence [ + sysw "-/class/sound/ctl-led/mic/card${CardNumber}/detach:Capture Switch" + ] + } True.Define.DeviceMic "Mic2" } This will work with the older kernels (errors are ignored) and with new kernels. And advanced users can change the behaviour on demand.
Fair enough (I still personally think a mute button should mute all inputs, but as I don't work in the audio stack I appreciate that's probably a discussion that was had a long time ago and will go back under my rock on that point). I can confirm the above change works and fixes the mute LED. Thank you! Are you happy to push this up to the alsa-ucm-conf project? Let me know if I can help with anything for the next steps. Mark
I confirm that bug is solved in the Kernel version: 6.0.11-300.fc37.x86_64
I still got the same issue on a X13 gen 3 AMD, even with 6.0.11-300.fc37.x86_64 So this should not apply only to the Intel architecture.
"Fix" for AMD (modify /usr/share/alsa/ucm2/HDA/HDA.conf): diff --git a/ucm2/HDA/HDA.conf b/ucm2/HDA/HDA.conf index 64ffe83..47dfc05 100644 --- a/ucm2/HDA/HDA.conf +++ b/ucm2/HDA/HDA.conf @@ -55,6 +55,7 @@ If.use { cset-new "name='Mic ACP LED Capture Switch' type=bool,count=1 off" exec "-/sbin/modprobe snd_ctl_led" sysw "-/class/sound/ctl-led/mic/card${CardNumber}/attach:Mic ACP LED Capture Switch" + sysw "-/class/sound/ctl-led/mic/card${CardNumber}/detach:Capture Switch" ] } } Could you report back, if it does work? Anyway, I would like to see rather that gnome or any other "Mute" key manager code will turn off _ALL_ sound inputs. Not just only integrated Mic.
Thanks, that works for AMD! However that file will probably be overwritten by the next alsa-ucm update?
FEDORA-2022-998f66b6ae has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-998f66b6ae
(In reply to daniel g. siegel from comment #23) > Thanks, that works for AMD! However that file will probably be overwritten > by the next alsa-ucm update? Don't worry, I'm the upstream maintainer and I already pushed this change to upstream :) F37 update is ready.
Fantastic - thanks Jaroslav - really appreciate your help getting this fixed. Mark
(In reply to Jaroslav Kysela from comment #25) > Don't worry, I'm the upstream maintainer and I already pushed this change to > upstream :) F37 update is ready. Awesome, thanks :)
FEDORA-2022-998f66b6ae has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-998f66b6ae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-998f66b6ae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The microphone LED works again for me on Thinkpad P1 gen3. Thanks.
FEDORA-2022-998f66b6ae has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
I'm still seeing this behavior (or a variation of it?). The OS acknowledges that the microphone is muted when I press the button, but the LED stays off. kernel-6.0.12-300.fc37.x86_64 alsa-lib-1.2.8-2.fc37.x86_64 Version: ThinkPad X1 Carbon Gen 9 (Not reopening yet in case this is a separate issue)
What is the contents of file /sys/class/sound/ctl-led/mic/card0/list file in your system? I assume that the sof-hda-dsp is first (zero) on the system (check with `aplay -l`).
(In reply to Jaroslav Kysela from comment #32) > What is the contents of file /sys/class/sound/ctl-led/mic/card0/list file in > your system? The file is empty. > I assume that the sof-hda-dsp is first (zero) on the system (check with > `aplay -l`). It's card 2: **** List of PLAYBACK Hardware Devices **** card 0: USB [ThinkPad Thunderbolt 3 Dock USB], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sofhdadsp [sof-hda-dsp], device 3: HDMI1 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sofhdadsp [sof-hda-dsp], device 4: HDMI2 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sofhdadsp [sof-hda-dsp], device 5: HDMI3 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sofhdadsp [sof-hda-dsp], device 31: HDA Analog Deep Buffer (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0
Then use /sys/class/sound/ctl-led/mic/card2/list file, of course.
(In reply to Jaroslav Kysela from comment #34) > Then use /sys/class/sound/ctl-led/mic/card2/list file, of course. Ah yes, sorry! That file contains 44
If there's only one value, it seems correct. Could you test Dmic0 control in `alsamixer -c 2` if the LED reflects changes ? Press F4 to select the capture controls and Space when Dmic0 is selected.
There are two Dmic0 devices in alsamixer, Dmic0 Front and Dmic0 Reader. When I mute either one of them individually, the LED remains off. When I mute them both, the LED turns on. But! KDE Plasma defaults to using the Dock USB input (as suggested by the aplay -l output). When I select the built-in microphone in Plasma's sound settings, the LED lights up when muting. It seems like the LED only reflects the state built-in sound card and not any additional devices, which makes sense, I suppose. I'm with Mark that I think the button should mute all inputs, but I understand from the conversation that's not the intended behavior. The behavior is a little confusing if you're not expecting it, but I think it can be said to work for the purposes of this bug, so I won't reopen.
Thanks Ben for the analysis. Basically, the ALSA mixer controls can be attached to the LED trigger mechanism using the driver (automatic / default configuration) or sysfs (user space, only with root privileges) for any sound card. The ALSA driver does not track, which inputs are really used, because the sound server control this (another layer). I think that there there may be more discussion about this with the window manager developers, because this mechanism is tied to the mute key handling (which is handled in the window manager - gnome/KDE). Eventually, it may be part of the sound server (pulseaudio or pipewire). The kernel sound LED driver may also handle the "Jack" state (physically connected / disconnected inputs). But in my opinion, Jack states are handled in the sound server already, so there is a room for the improvement. We may think also about security - if we allow to change the LED behavior dynamically in the user space by desktop users, we should use a policy to not allow to change the kernel settings from any application.
Finally updated to Fedora 37 to test the fix and it indeed works. Thanks.
There is another bug related to this feature. If you plug in an external input device (headphones for example) the led is always on; so if you push the button to mute the headphone mic, the led remains on.
It was already explained in comment#12 and comment#38. With this change, microphone LED is attached only to the internal microphone, because users expect that behaviour. If we revert this, the sound server / window manager (mute key event handler) should MUTE all internal inputs (internal microphone + analog jack) to turn the LED on.
And why this doesn't apply to the Volume Mute button, but only to the microphone mute button? In my opinion, this is not intuitive. When I plug in my headphone, in my opinion, it's intuitive that my "dashboard" (my led set) shot to me the status of the "audio device" that I'm currently using.