Created attachment 289561 [details] alsa-info Mute LEDs present on the HP Spectre x360 (13-aw0xxx) keyboard's speaker mute and microphone mute buttons don't light up regardless of the devices' state. As I've documented on the Arch wiki (https://wiki.archlinux.org/index.php/HP_Spectre_x360_-_13-aw0xxx#Audio) to get both the ALC285 speakers and microphone working I had to blacklist snd-hda-intel and snd-soc-skl and add explicit mappings to /etc/pulse/default.pa. Basing on bug 195827, comment 6 I've tried poking at the GPIO pins and discovered that pin 4 handles the mic mute LED. Running: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x04 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x04 Turns the LED on, and finally running: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04 Turns it off and makes it unresponsive until reboot. Cycling through the rest of the pins had no effect on the speakers mute LED, which always stayed off. Being forced to use the snd_sof_pci module to get the microphone to be detected, I can't use snd-hda-intel's "model" option to forcibly activate a quirk like the one that was posted on the ALSA mailing list two months ago: https://mailman.alsa-project.org/pipermail/alsa-devel/2020-April/165555.html I've also tried applying this patch - https://patchwork.kernel.org/patch/11271559/ - to port that option over to the SOF module but I didn't get any result by playing around with different model values, given that my patching was done properly. That can be seen in the attached alsa-info output, along with some dmesg noise due to utilizing a temporary USB sound card for tests.
Could you try the following patch?
Created attachment 289703 [details] Fix patch
Thanks, I've applied it but now the mic mute LED acts like the speakers mute indicator and it's possibly inverted: > Speakers unmuted: speakers mute LED off, mic mute LED on. > Speakers muted: speakers mute LED off, mic mute LED off. The speakers mute LED always stays off. I've also tried using the `ALC285_FIXUP_HP_MUTE_LED` quirk but no LEDs light up that way.
Additionally, the above is true when the workarounds mentioned in comment 1 are NOT applied and the `snd_hda_intel` module is handling the sound card (and thus no microphone is detected). With those workarounds applied and `snd_sof` handling the card, your patch makes the mic mute LED always stay on; the speakers mute LED always stays off as before. The output of `grep "IO\[" /proc/asound/card0/codec\#0` when the mic mute LED is on is: IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 And when the mic mute LED is off it's: IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0 Is there a more precise way I can poke at the codec's GPIO pins?
My bad, this was a wrong hook. GPIO 0x04 is for the mic, not for the speaker mute. Is any other GPIO pin corresponding to the speaker mute LED? Is it only the mic mute LED? The existing quirk doesn't match with your setup, so we'd need to create a new one instead. And, if you change the driver, you shouldn't pass any model option, no matter to snd-hda-intel or SOF. Let the driver choose its default.
Now I saw that you've set model=hp-gpio-led, and I assume that corresponds to the speaker mute LED working. With that assumption, below is the revised patch. Please try it and drop the model option.
Created attachment 289715 [details] Revised test fix patch
I'm sorry, the model parameter was probably a leftover from trying the relative SOF patch and didn't have any useful effect, please ignore it. I'm attaching a clean alsa-info report taken on a freshly booted and unpatched kernel with SOF being forced instead of snd-hda-intel (otherwise no mic gets recognized and I can't test muting it). I've poked at all three GPIO pins and various combinations of them (with an unpatched kernel, so that no driver would interfere), but so far it seems that the only useful one is 0x04 for controlling the mic mute LED. Is there anywhere else that I should check for an exposed interface of the speaker mute LED? Thanks a lot for all the help so far.
Created attachment 289717 [details] alsa-info
OK, then the mute LED must be controlled differently. I found that other models use also the MIC pin (NID 0x1b) vref change for toggling that. Below is the revised patch. Please give it a try. Note that it's generated for the latest source, and you might need to modify it slightly to adapt to the old kernel.
Created attachment 289811 [details] Revised test patch
With this new patch, despite the mic mute LED initially always staying off regardless of the actual mic mute status, new elements for both the speakers and the mic mute LEDs have popped up in alsamixer: "Mute-LED Mode" and "Mic Mute-LED Mode". I can manually toggle the mic mute LED by setting "Mic Mute-LED Mode" to On and Off, while Follow Mute makes it always stay off and Follow Capture makes it always stay on. I've played with PulseAudio but I couldn't get the LED to react to the actual mute status. The speakers mute LED instead, as expected given the contents of the patch, always stays off regardless of the "Mute-LED Mode" value.