New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ThinkPad T14 AMD microphone LED always ON #100
Comments
Yes, the problem with this hw is that it has only software mute control, so we need to handle it differently than for other devices. The UCM is ready to support this. I'll prepare some test configs when we have the testers, soon. |
Great, good to know that you are aware of this. Thanks! |
Btw, this hw needs |
It's an AMD platform, but the microphone is connected to the AMD ACP sound bridge (it's not HDA sound bridge). The sof-firmware is required only for Intel hardware. |
Hi, any news on this? |
This issue hasn't been resolved yet. Using latest version of Arch 5.13.12. I can manually change the microphone LED and the button works. However the LED does not reflect the current state of the microphone. |
Could you test changes in #115 ? |
For me it doesn't work. |
Could you elaborate more? A reboot is required to let the alsactl utility to create the new control at boot (check journal for alsa-state service for errors) and you should see 'Mic ACP LED' control in alsamixer for the HDA card. |
Well, I did reboot after editing both files What do you mean by 'new control'? Is this supposed to circumvent the keyboard Fn key to achieve a working LED? |
You're using very high level. It's not about key mappings. I need to go down to the ALSA subsystem basics and test things one by one. So, could you show me the alsactl log after boot - |
'Mic ACP LED' control doesn't appear.
There is one UCM error in the logs.
Kernel 5.14.16 |
The FixedBootSequence should be executed with command Verification:
|
Tested with whole tree from PR and 'Mic ACP LED Switch' appears when listing controls. |
If |
Yes, that's right. I can mute/unmute the new control on alsamixer and the LED switches states. On the other hand, this has nothing to do with Mic status, which remains the same. I guess that now both things have to be connected somehow, right? |
Pulseaudio or pipewire should change the state this control when the microphone is active / inactive. It's the change in Does it work in the sound server? Note that all microphone inputs must be off (including the headphone / headset mic). |
I've checked with pavucontrol:
|
Thank you for the feedback. I updated the code in my pull request. The |
Same behaviour. Btw, PR is not updated. I just put the change myself. |
Could you show the pulseaudio debug log ? https://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems The PR is updated now (pushed changes to other repo originally). |
No errors so far:
|
Please, show the full log (use https://gist.github.com/ or https://pastebin.com for example). I need to check, why the switch in mixer is not detected. |
Here you have. |
PA ignores this mixer control, checking why: D: [pulseaudio] alsa-mixer.c: Probing path 'Mic ACP LED' D: [pulseaudio] alsa-mixer.c: Probe of element 'Mic ACP LED' succeeded (volume=0, switch=0, enumeration=0, has_dB=0). W: [pulseaudio] alsa-ucm.c: Path Mic ACP LED is not a volume control |
Could you dump smixer contents, please? |
Perhaps, the capture direction is missing in the control name (PR is updated): diff --git a/ucm2/HDA-Intel/HDA-Intel.conf b/ucm2/HDA-Intel/HDA-Intel.conf index 7bc5f7f..78b46f0 100644 --- a/ucm2/HDA-Intel/HDA-Intel.conf +++ b/ucm2/HDA-Intel/HDA-Intel.conf @@ -30,9 +30,9 @@ If.use { Include.init.File "/HDA-Intel/init.conf" FixedBootSequence [ diff --git a/ucm2/HDA-Intel/HDA-Intel.conf b/ucm2/HDA-Intel/HDA-Intel.conf index 7bc5f7f..78b46f0 100644 --- a/ucm2/HDA-Intel/HDA-Intel.conf +++ b/ucm2/HDA-Intel/HDA-Intel.conf @@ -30,9 +30,9 @@ If.use { Include.init.File "/HDA-Intel/init.conf" FixedBootSequence [ - cset-new "name='Mic ACP LED Switch' type=bool,count=1 off" + 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 Switch" + sysw "-/class/sound/ctl-led/mic/card${CardNumber}/attach:Mic ACP LED Capture Switch" ] } True { diff --git a/ucm2/HDA-Intel/HiFi-acp.conf b/ucm2/HDA-Intel/HiFi-acp.conf index ead8646..a650f5c 100644 --- a/ucm2/HDA-Intel/HiFi-acp.conf +++ b/ucm2/HDA-Intel/HiFi-acp.conf @@ -5,6 +5,6 @@ SectionDevice."Mic1" { CapturePriority 100 CapturePCM "hw:${var:AcpCardId}" CaptureMixerElem "Mic ACP LED" - CaptureSwitch "Mic ACP LED Switch" + CaptureSwitch "Mic ACP LED Capture Switch" } } |
Now 'Mic ACP LED' went to With pavucontrol same as before. |
I found it. The mixer devices must be different in HiFi-acp.conf:
The PR was updated. |
Same result, LED only reacts to mute/unmute of Headphones Stereo Mic when using pavucontrol. |
Thanks for finding out Jaroslav! Should we expect a new release or is it a matter of alsa packagers on every distro? |
Bug for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2049728 |
In my case LED works sometimes, for instance today. How the selinux issue explains this? Total honest question. No idea about it. How can I check selinux policy on my Arch system? Edit: |
Confirmed. After reboot LED stopped working. What I notice is a different device order on KDE sound applet this time, so maybe card detection order could be causing the issue. I have to double check on this. |
You may try add -d option to alsactl calls (/lib/systemd/system/alsa*.service) to get more info. I also added the serialization lock guard in the latest alsactl - alsa-project/alsa-utils@8403967 . It may also help in your case. |
Here are the results with debug enabled. When it worked:
On subsequent boots it didn't work anymore:
I've double checked device order on KDE sound applet and it was consistent for every boot. |
It seems that |
This is the rule and for some reason it must not be working:
|
Right, the RUN call should be also checked (-d argument and redirection of stderr). |
For some reason this specific rule is not being triggered. This is what I did:
With this in place nothing shows on boot logs not even on For some reason I don't remember now I had disabled |
I've managed to trigger the problem consistently, at least a couple of times. It's really weird. Whenever I poweroff the laptop, LED works on next boot. If I just reboot it doesn't. That's it, quite strange and maybe indicative of a much deeper issue on this specific platform. |
I have a ThinkPad Z13 (AMD) and am seeing the same issue. On an Arch Linux with Here is my
Here are some udev debug logs, with And this is what happens after running
|
@hexchain : Which distro ?
It may be also a SELinux issue or so... |
@perexg Sorry, it's on Arch Linux, it doesn't have SELinux. |
I have a Thinkpad P14s AMD Gen 2 And i can confirm the same issue as @hexchain . Issuing the command Edit : Running Arch 6.0.5 and tried older kernels with no luck. Edit 2 : Tried Ubuntu and the OEM version and basically is works half as expected. Plug a headset Mic in, mute the headset mic via LED mic mute button, unplug it and click on the LED mic mute and the LED doesn't work anymore unless I manually open alsamixer and mute the Basically on Ubuntu: |
For me, this issue seems to go away after upgrading to 6.0. The Mic Mute LED works every time for the internal microphone after boot. But I don't have a headset with a mic, so I cannot test the above scenario. |
I think I've fixed it on my end. The problem is I don't know exactly what I did to fix it. On my AMD ThinkPad P14s Gen 2 my mic mute LED was always on, independently if I muted or un-muted the mic. I've opened alsamixer and I'm not sure what did it, but I think I just changed the sound card (F6) and disabled the Auto-Mute Mode. Then I rebooted and turned it back on. Not sure if this is what fixed it, but seems like so. This is on Arch Linux on kernel 6.4.12 |
T14s Gen 1 here. No success with any of these suggestions, I'm afraid. The mic mutes and unmutes when pressed, just the LED will stay constantly on. I'm on |
I'm on a ThinkPad T14s Gen 1 AMD here, and this problem has been solved months ago. Like at least 5 months ago now. Using Arch Linux 6.5.2 with Hyprland and Sway. Using pipewire rather than pulseaudio. |
Yeah, mine is AMD as well, and running pipewire rather than pulseaudio too. I'm glad it's working for you. Can you point to the fix or how you managed to make it behave accordingly? |
Honestly I didn't take any specific steps to fix it, I had just reinstalled arch and magically it was fixed. I would recommend you install arch or some other arch based distro onto a live USB to test if it works there. If it does then doing the same thing might fix it. Also I should mention my firmware is also updated to the latest version with fwupd incase that for some reason plays a role. |
Thanks! I'm already on a bleeding-edge distro, so that shouldn't be the issue, I hope. I've dug a bit around, and while using |
@devhell I can reproduce the same exact pattern here. Pipewire does not control the led, alsamixer can toggle it manually when I use pipewire-alsa and pipewire. The hardware button does not toggle its state. I'm on the latest archlinux packages |
If it helps, randomly installing pipewire-alsa and alsautils, then running |
@nishanthkarthik I honestly don't know how I did it, but mine is working correctly even after reboot. |
No worries. Yes, tried your solution, but after the reboot it was re-enabled again. |
I currently have the same issue, I have a T14 AMD with kernel 6.1.58. |
I just bought a P14S Gen 1 and I have this issue as well.
|
@nfp0 Thanks a lot, your solution has fixed the issue (Mic Mute Led always on) for me as well on AMD ThinkPad P16s Gen 2.
Just as a note, the solutions from either of these pages didn't work for me. I assume that the solution from the second page probably doesn't work now because Mic LED controls were removed from alsamixer as explained here. |
I'm running Arch Linux with
alsa-ucm-conf
1.2.5.1. This problem was present in previous versions and it's being discussed on a forum thread among other things.So the problem is that microphone LED is always ON but mute/unmute behaviour still works.
The text was updated successfully, but these errors were encountered: