ThinkPad T14 AMD microphone LED always ON

[miquecg]

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.

[devhell]

This is awesome, I have the same issue with my T14s, thank you for looking into it!

[tvlpirb]

Thank you, I'm testing it on my T14s as well and that works!

[perexg]

1.2.6 is out with this change.

[j1cs]

Hi guys! the problem still persist on my ThinkPad T14 Gen 1 AMD. when I press the key on the keyboard to turn off the microphone it turns off the headphone instead of the built-in. @perexg hoping not bothering you: what kind of information from my laptop can be useful to see why the problem occurs

[perexg]

@j1cs : I don't think that audio key-press mapping is UCM related. The audio key bindings is located usually in the X-window manager (gnome-shell or so). I assume that the direct mute in pulseaudio / pipewire works.

[j1cs]

@j1cs : I don't think that audio key-press mapping is UCM related. The audio key bindings is located usually in the X-window manager (gnome-shell or so). I assume that the direct mute in pulseaudio / pipewire works.

I'm sorry I'm meant the led. The led indicates mute status of the headset rather than the internal microphone. I'm using gnome with pulseaudio. I found this and I believe is related https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1849

[perexg]

The Mic LED may follow the both internal and headphone microphone (so it turns on only when both of them are off). You may check, if there are multiple bindings using sysfs:

for i in $(cat /sys/class/sound/ctl-led/mic/card*/list); do echo $i; echo; done

[j1cs]

for i in $(cat /sys/class/sound/ctl-led/mic/card*/list); do echo $i; echo; done

$ for i in $(cat /sys/class/sound/ctl-led/mic/card*/list); do echo $i; echo; done
bash: warning: command substitution: ignored null byte in input
7

I made a video to illustrate better https://youtu.be/mDwKmdjDzbU As you can see when I click the mute button from the mic the led blinks

[perexg]

It's pulseaudio or pipewire backend? If you watch the amixer -c 0 events on terminal (replace 0 with the correct ALSA card number - the one with Headphone controls), what changes when you toggle 'Headphone' mute ?

[j1cs]

I'm using pulseaudio

$ amixer -c 1 events
event add: numid=12,iface=CARD,name='Headphone Jack'
event add: numid=11,iface=CARD,name='Mic Jack'
event add: numid=13,iface=CARD,name='Speaker Phantom Jack'
event add: numid=10,iface=MIXER,name='Master Playback Switch'
event add: numid=9,iface=MIXER,name='Master Playback Volume'
event add: numid=2,iface=MIXER,name='Headphone Playback Switch'
event add: numid=1,iface=MIXER,name='Headphone Playback Volume'
event add: numid=8,iface=MIXER,name='Mic Boost Volume'
event add: numid=7,iface=MIXER,name='Capture Switch'
event add: numid=6,iface=MIXER,name='Capture Volume'
event add: numid=5,iface=MIXER,name='Auto-Mute Mode'
event add: numid=4,iface=MIXER,name='Speaker Playback Switch'
event add: numid=3,iface=MIXER,name='Speaker Playback Volume'
event add: numid=15,iface=PCM,name='Capture Channel Map'
event add: numid=14,iface=PCM,name='Playback Channel Map'
Ready to listen...
Poll ok: 1
event value: numid=7,iface=MIXER,name='Capture Switch'
event value: numid=7,iface=MIXER,name='Capture Switch'
event value: numid=7,iface=MIXER,name='Capture Switch'
event value: numid=7,iface=MIXER,name='Capture Switch'

I turned on and off the mic with pavucontrol. That's why it show four times. Doesn't display anything with the integrate mic.

[perexg]

Did you reboot your laptop after installation of ALSA 1.2.6 ? The 'Mic ACP LED' switch is not created (it is created only during boot). Also, the alsa-state.service (systemd) should be started on boot to activate this thing.

[j1cs]

Yes I rebooted. I think I'm going to have to follow another strategy since I'm not using systemd. I use Artix with Runit so I will have to see how to translate the systemd service to a script in runit.

Update: I found these scripts https://github.com/void-linux/void-packages/tree/master/srcpkgs/alsa-utils/files/alsa and i have an eternal loop:

Ready to listen...
Poll ok: 1
event remove: numid=134,iface=MIXER,name='Mic ACP LED Capture Switch'
event add: numid=135,iface=MIXER,name='Mic ACP LED Capture Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event remove: numid=135,iface=MIXER,name='Mic ACP LED Capture Switch'
event add: numid=136,iface=MIXER,name='Mic ACP LED Capture Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event remove: numid=136,iface=MIXER,name='Mic ACP LED Capture Switch'
event add: numid=137,iface=MIXER,name='Mic ACP LED Capture Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event remove: numid=137,iface=MIXER,name='Mic ACP LED Capture Switch'
event add: numid=138,iface=MIXER,name='Mic ACP LED Capture Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event remove: numid=138,iface=MIXER,name='Mic ACP LED Capture Switch'
event add: numid=139,iface=MIXER,name='Mic ACP LED Capture Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event remove: numid=139,iface=MIXER,name='Mic ACP LED Capture Switch'
event add: numid=140,iface=MIXER,name='Mic ACP LED Capture Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event value: numid=10,iface=MIXER,name='Master Playback Switch'
event remove: numid=140,iface=MIXER,name='Mic ACP LED Capture Switch'

in addition to the output loop, the volume led flashes at the same time as the amixer log. it's turn on and off on every new output comming from the amixer command.

[j1cs]

Ok I made script for state and the led and now is working. thank for your advice.

[miquecg]

Hi again.

Today after a kernel update something may have changed, because now LED is tracking Headphone Mic instead of Digital Mic.

It also disappeared from amixer:

numid=12,iface=CARD,name='Headphone Jack'
numid=11,iface=CARD,name='Mic Jack'
numid=13,iface=CARD,name='Speaker Phantom Jack'
numid=10,iface=MIXER,name='Master Playback Switch'
numid=9,iface=MIXER,name='Master Playback Volume'
numid=2,iface=MIXER,name='Headphone Playback Switch'
numid=1,iface=MIXER,name='Headphone Playback Volume'
numid=8,iface=MIXER,name='Mic Boost Volume'
numid=7,iface=MIXER,name='Capture Switch'
numid=6,iface=MIXER,name='Capture Volume'
numid=5,iface=MIXER,name='Auto-Mute Mode'
numid=4,iface=MIXER,name='Speaker Playback Switch'
numid=3,iface=MIXER,name='Speaker Playback Volume'
numid=15,iface=PCM,name='Capture Channel Map'
numid=14,iface=PCM,name='Playback Channel Map'

Now alsamixer shows Mic ACP LED on a different device:

Card HD-Audio Generic
Chip ATI R6xx HDMI
View Capture

I think yesterday it was under:

Card HD-Audio Generic
Chip Realtek ALC257
View Playback

Now there's an element labeled Capture on this second card that toggles LED on and off.

With pavucontrol I can also control the LED but is attached to Headphone Mic.

[perexg]

The HDMI fix is here: 369f8b497e15a993d411df81a39ee5c8c1433363 . Could you confirm that the kernel upgrade changed the behaviour ?

[miquecg]

Yes, after downgrading kernel Mic ACP LED came back and also worked.

What puzzles me is that upgrading didn't change anything and LED kept working. The only difference now is the kernel version the system upgraded to.

Before:

5.16.2 -> 5.16.3

Now:

5.16.2 -> 5.16.4

[miquecg]

Well, today LED disappeared again from controls. So this is the thing, there must be some condition at boot that sometimes happens out of order and breaks LED.

What could it possibly be?

[perexg]

Crosslinking another report: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1849

[perexg]

Do you see any errors in log for the alsa-state service? journalctl -u alsa-state?

[bdaase]

Crosslinking another report: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1849

I am the reporter in the other issue. For me, the LED has to be attached on every boot, independent of the kernel version (I am currently running 5.17.rc2). It looks as follows

echo -n "Mic ACP LED Capture Switch" | sudo tee /sys/class/sound/ctl-led/mic/card1/attach

However, it isn't always card1 but changes on every boot (to either card0, card1,or card2). This seems to be the case because my system seems to report actually three sound cards

➜  ~ cat /proc/asound/cards
 0 [acp            ]: acp - acp
                      LENOVO-21A1S00D00-ThinkPadP14sGen2a
 1 [Generic        ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfd3c8000 irq 118
 2 [Generic_1      ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfd3c0000 irq 119

that permutate randomly every time.

alsa-state also doesn't seem to report any issues

➜  ~ journalctl -u alsa-state -b 0
Jan 31 21:33:36 p14s-gen2-amd systemd[1]: Started Manage Sound Card State (restore and store).
Jan 31 21:33:36 p14s-gen2-amd alsactl[1008]: alsactl 1.2.6 daemon started

[miquecg]

Do you see any errors in log for the alsa-state service? journalctl -u alsa-state?

Yep. It looks like my system is running alsa-restore but not alsa-state. Not sure if that makes any difference because sometimes LED works, as I reported.

These messages have been there for quite some time:

➜  ~ journalctl -u alsa-state
systemd[1]: Manage Sound Card State (restore and store) was skipped because of a failed condition check (ConditionPathExists=/etc/alsa/state-daemon.conf).

➜  ~ cat /proc/asound/cards
 0 [Generic        ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfd3c8000 irq 109
 1 [Generic_1      ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfd3c0000 irq 110
 2 [acp            ]: acp - acp
                      LENOVO-20UDCTO1WW-ThinkPadT14Gen1

[perexg]

Then inspect the log for alsa-restore. Both services are doing the initialization on boot.

[miquecg]

Then inspect the log for alsa-restore. Both services are doing the initialization on boot.

➜  ~ journalctl -u alsa-restore
feb 01 11:45:39 systemd[1]: Starting Save/Restore Sound Card State...
feb 01 11:45:39 systemd[1]: Finished Save/Restore Sound Card State.
feb 01 11:48:45 systemd[1]: Stopping Save/Restore Sound Card State...
feb 01 11:48:45 systemd[1]: alsa-restore.service: Deactivated successfully.
feb 01 11:48:45 systemd[1]: Stopped Save/Restore Sound Card State.

It looks fine.

[bdaase]

➜  ~ journalctl -u alsa-restore -b 0
Jan 31 21:33:36 p14s-gen2-amd systemd[1]: Condition check resulted in Save/Restore Sound Card State being skipped.

[perexg]

After some debugging, it looks like a selinux issue. The rules should be updated to allow the sysfs write and modprobe.

module alsactl 1.0;

require {
    type sysfs_t;
    type kmod_exec_t;
    type alsa_t;
    class file { execute write };
}

#============= alsa_t ==============
allow alsa_t kmod_exec_t:file execute;
allow alsa_t sysfs_t:file write;

[bdaase]

Thanks a lot Jaroslav, that's it indeed!

I set selinux to permissive mode, rebooted and voilà, the LED is attached correctly instantly without having to invoke any command manually.

[miquecg]

Thanks for finding out Jaroslav! Should we expect a new release or is it a matter of alsa packagers on every distro?

[perexg]

Bug for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2049728

[miquecg]

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: Looks like it's not activated on Arch by default: https://wiki.archlinux.org/title/SELinux

[miquecg]

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.

[perexg]

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 - https://github.com/alsa-project/alsa-utils/commit/8403967669eaa9405a43d430b4ac7e5f0ea1b75e . It may also help in your case.

[miquecg]

Here are the results with debug enabled.

When it worked:

feb 03 11:57:25 systemd[1]: Starting Save/Restore Sound Card State...
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1499: device='hw:0', doit=0
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'Generic'
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1546: list count: 22
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1574: maxnumid=22 maxnumid2=22
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1499: device='hw:0', doit=1
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'Generic'
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1499: device='hw:1', doit=0
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'Generic_1'
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1546: list count: 16
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1574: maxnumid=15 maxnumid2=16
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1579: more controls than maxnumid?
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1587: result code: -11
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: sysfs_init:45: sysfs_path='/sys'
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1499: device='hw:1', doit=1
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'Generic_1'
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1499: device='hw:2', doit=0
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'acp'
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1546: list count: 0
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1574: maxnumid=-1 maxnumid2=-1
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1499: device='hw:2', doit=1
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'acp'
feb 03 11:57:25 alsactl[849]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 11:57:25 systemd[1]: Finished Save/Restore Sound Card State.
feb 03 11:58:03 systemd[1]: Stopping Save/Restore Sound Card State...
feb 03 11:58:03 systemd[1]: alsa-restore.service: Deactivated successfully.
feb 03 11:58:03 systemd[1]: Stopped Save/Restore Sound Card State.

On subsequent boots it didn't work anymore:

feb 03 11:58:23 alsactl[826]: /usr/bin/alsactl: set_controls:1499: device='hw:0', doit=0
feb 03 11:58:23 alsactl[826]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'Generic'
feb 03 11:58:23 alsactl[826]: /usr/bin/alsactl: set_controls:1546: list count: 22
feb 03 11:58:23 alsactl[826]: /usr/bin/alsactl: set_controls:1574: maxnumid=22 maxnumid2=22
feb 03 11:58:23 alsactl[826]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 11:58:23 alsactl[826]: /usr/bin/alsactl: set_controls:1499: device='hw:0', doit=1
feb 03 11:58:23 alsactl[826]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'Generic'
feb 03 11:58:23 alsactl[826]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 11:58:22 systemd[1]: Starting Save/Restore Sound Card State...
feb 03 11:58:23 systemd[1]: Finished Save/Restore Sound Card State.
feb 03 12:02:59 systemd[1]: Stopping Save/Restore Sound Card State...
feb 03 12:02:59 systemd[1]: alsa-restore.service: Deactivated successfully.
feb 03 12:02:59 systemd[1]: Stopped Save/Restore Sound Card State.
-- Another boot --
feb 03 12:03:58 alsactl[797]: /usr/bin/alsactl: set_controls:1499: device='hw:0', doit=0
feb 03 12:03:58 alsactl[797]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'Generic'
feb 03 12:03:58 alsactl[797]: /usr/bin/alsactl: set_controls:1546: list count: 22
feb 03 12:03:58 alsactl[797]: /usr/bin/alsactl: set_controls:1574: maxnumid=22 maxnumid2=22
feb 03 12:03:58 alsactl[797]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 12:03:58 alsactl[797]: /usr/bin/alsactl: set_controls:1499: device='hw:0', doit=1
feb 03 12:03:58 alsactl[797]: /usr/bin/alsactl: set_controls:1511: card-info-id: 'Generic'
feb 03 12:03:58 alsactl[797]: /usr/bin/alsactl: set_controls:1587: result code: 0
feb 03 12:03:57 systemd[1]: Starting Save/Restore Sound Card State...
feb 03 12:03:57 systemd[1]: Finished Save/Restore Sound Card State.

I've double checked device order on KDE sound applet and it was consistent for every boot.

[perexg]

It seems that Generic_1 card is not found (initialized). It looks like a timing issue. The udev rule /lib/udev/rules.d/90-alsa-restore.rules should handle this situation (card appears later after alsa-restore service).

[miquecg]

This is the rule and for some reason it must not be working:

➜  ~ cat /lib/udev/rules.d/90-alsa-restore.rules
ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/bin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", RUN+="/usr/bin/alsactl restore $attr{device/number}"
TEST=="/etc/alsa/state-daemon.conf", RUN+="/usr/bin/alsactl nrestore $attr{device/number}"

LABEL="alsa_restore_end"

[perexg]

Right, the RUN call should be also checked (-d argument and redirection of stderr).

[miquecg]

For some reason this specific rule is not being triggered. This is what I did:

• Change RUN commands: RUN+="/usr/bin/alsactl -d restore $attr{device/number} 2>&1 and same to the other
• Activate debug in /etc/udev/udev.conf

With this in place nothing shows on boot logs not even on systemd-udev unit logs. So I went to manually trigger the rules with command: udevadm trigger -s sound. Same result, that specific rule didn't fire but 60-persistent-alsa.rules did it.

For some reason I don't remember now I had disabled 90-alsa-restore.rules with a symlink to /dev/null on /etc/udev/rules.d. When I realized that I just removed the link and tested again.

[miquecg]

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.

[hexchain]

I have a ThinkPad Z13 (AMD) and am seeing the same issue. On an Arch Linux with alsa-ucm-conf 1.2.7.2, the mic-mute LED doesn't work after a reboot. In alsamixer there is a "Mic ACP LED" control, but toggling that does nothing. However, when it happens, running alsactl restore fixes the issue until the next reboot.

Here is my /proc/asound/cards:

 0 [Generic        ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xb0ac8000 irq 121
 1 [Generic_1      ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xb0ac0000 irq 122
 2 [acp6x          ]: acp6x - acp6x
                      LENOVO-21D2CTO1WW-ThinkPadZ13Gen1

Here are some udev debug logs, with -d appended to the RUN line: udev-alsa.log Here are some output from alsa-restore.service, also with -d added: alsa-restore.log

And this is what happens after running alsactl -d restore 1 manually:

% sudo alsactl -d restore 1
alsactl: init_ucm:48: ucm open '-hw:1': 0
alsactl: init_ucm:53: ucm _fboot: 0
alsactl: set_controls:1499: device='hw:1', doit=0
alsactl: set_controls:1511: card-info-id: 'Generic_1'
alsactl: set_controls:1546: list count: 17
alsactl: set_controls:1574: maxnumid=18 maxnumid2=17
alsactl: set_controls:1579: more controls than maxnumid?
alsactl: set_controls:1587: result code: -11
alsactl: sysfs_init:45: sysfs_path='/sys'
alsactl: init_ucm:48: ucm open '-hw:1': 0
alsactl: init_ucm:62: ucm _boot: 0
alsactl: set_controls:1499: device='hw:1', doit=1
alsactl: set_controls:1511: card-info-id: 'Generic_1'
alsactl: set_controls:1587: result code: 0

[perexg]

@hexchain : Which distro ?

'/usr/bin/alsactl: init_ucm:48: ucm open '-hw:0': -6'
'/usr/bin/alsactl: init_ucm:48: ucm open '-hw:1': -6'

It may be also a SELinux issue or so...

[hexchain]

@perexg Sorry, it's on Arch Linux, it doesn't have SELinux.

[Bodanor]

I have a Thinkpad P14s AMD Gen 2 And i can confirm the same issue as @hexchain . Issuing the command alsa restore, makes the mic led work again until the next reboot. Seems like Mic ACP LED and Capture are in conflict

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 Capture input

Basically on Ubuntu: Computer boots : Microphone' → mute/unmute LED ✅ Plug Headset Mic: Microphone' → mute/unmute LED ✅ Mute Headset Unplug Headset Mic: Microphone' → mute/unmute LED ❌

[hexchain]

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.

[nfp0]

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

[devhell]

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 6.5.1. I'm on sway, so no DE.

[tvlpirb]

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 6.5.1. I'm on sway, so no DE.

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.

[devhell]

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 6.5.1. I'm on sway, so no DE.

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?

[tvlpirb]

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 6.5.1. I'm on sway, so no DE.

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.

[devhell]

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 6.5.1. I'm on sway, so no DE.

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 alsamixer, I've switched to the Realtek AC257 sound card, and then toggling Capture actually makes the LED correspond with the state. When pressing the hardware button, the Capture doesn't change its state, and neither does the LED. However, PipeWire will happily indicate that the microphone is muted and unmuted. So, not sure what's going on there. But alsamixer being able to toggle the LED is promising, so maybe this is a PEBCAK issue of some sort. I'll see what I can find. Thank you!

[nishanthkarthik]

@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

[nishanthkarthik]

If it helps, randomly installing pipewire-alsa and alsautils, then running sudo alsactl restore, followed by playing with alsamixer followed by uninstalling alsamixer and pipewire-alsa fixes it (only until next reboot). I have not figured out the exact pattern required because it is not consistent.