Bug 213507 - ALC245/ALC701 Mute Mic/Sound LEDs are not functional on HP Envy x360 13-ay0015ur
Summary: ALC245/ALC701 Mute Mic/Sound LEDs are not functional on HP Envy x360 13-ay0015ur
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Jaroslav Kysela
Depends on:
Reported: 2021-06-19 21:24 UTC by Mikhail "L117" Nikolenko
Modified: 2024-03-20 10:45 UTC (History)
3 users (show)

See Also:
Kernel Version: 5.12.12-300.fc34.x86_64
Regression: No
Bisected commit-id:

alsa-info.sh output (37.76 KB, text/plain)
2021-06-19 21:24 UTC, Mikhail "L117" Nikolenko

Description Mikhail "L117" Nikolenko 2021-06-19 21:24:12 UTC
Created attachment 297491 [details]
alsa-info.sh output

Mute and Mic mute LEDs are not woking on this device. And it seems there are no model options to try with ALC245 (According to https://www.kernel.org/doc/html/v5.12/sound/hd-audio/models.html). 

Maybe device is not detected correctly?
If so, and there're actually options to try, please, explain me how.

I have attached output of alsa-info.sh and will provide more information if needed. Thanks.
Comment 1 Mikhail "L117" Nikolenko 2021-06-28 04:55:34 UTC
I did some more research and figured out that I have bugged BIOS, according to https://bugzilla.kernel.org/show_bug.cgi?id=70991 .
Now there's another problem: hda-verb does not work as in examples in link above.
It seems like I need four arguments instead of three:

usage: hda-verb [option] hwdep-device nid verb param

I guess "hwdep-device" should be one of devices in /dev/snd. What is "nid"? "verb" and "param" seem to be self-explanatory.
Comment 2 Mikhail "L117" Nikolenko 2021-06-28 07:01:00 UTC
Okay, so I messed up a bit with `hda-verb`. This command sequence turns MicMute led on:

hda-verb $device 0x1 SET_GPIO_MASK 0x4
hda-verb $device 0x1 SET_GPIO_DIRECTION 0x4
hda-verb $device 0x1 SET_GPIO_DATA 0x1

Some other parameters turn it off. But I can't find any documentation on how these verbs supposed to work. I clearly don't understand how this works, my aussumption was:

SET_GPIO_MASK - selects pins/registers/bits/whatever. Acts like bitmask? E.g. 0x1=first, 0x3=first+second, 0x4=third?
SET_GPIO_DIRECTION - read/write, I guess? I have no idea what values are valid.
SET_GPIO_DATA - 0x0=off, 0x1=on?
Comment 3 Mikhail "L117" Nikolenko 2021-06-28 07:03:13 UTC
Are bits sticky, or they act more like "impulse"?
Comment 4 Mikhail "L117" Nikolenko 2021-06-28 07:58:07 UTC
Page 172.

The bits are sticky.

All 3 verbs are actually masks.
0b00100000 = 4 = 0x4
SET_GPIO_MASK 0x4  activates third bit.
SET_GPIO_DIRECTION 0x4 puts third bit into write mode.
SET_GPIO_DATA 0x4 set third bit to 1.

This disables MicMute led, thus it is inverted. Ok.

Now I need to do something about Mute led. None of the bits control it, so I need either to try other devices, or "nid"s (I have no idea what are they).
Comment 5 Mikhail "L117" Nikolenko 2021-06-28 10:34:49 UTC
"nid" seems to be "Node ID". So, i tried to use hda-verb on each of them, for each of first 8 bits. NOnly MuteMic led works. It seems I can't do anything else.

And by the way, dmidecode contains exactly one line with "ALC", and it is "ALC701", no "ALC245".
Comment 6 Mikhail "L117" Nikolenko 2021-07-08 04:40:06 UTC
This laptop has 256-pin GPIO contoller. If I enable pins via `hda-analyzer` and then try to use `gpioset` with various arguments I can toggle state of MicMute led. But again, Mute led is not working. I'll try to use Windows and figure out what pins should be enabled/set, it this at all possible.

I've also posted a question on HP forums. But I doubt they'll give me schematic.
Comment 7 Tom 2024-03-20 10:45:25 UTC
a fix for the ay-series has been merged into the kernel: https://lore.kernel.org/all/651b26e9-e86b-45dd-aa90-3e43d6b99823@catboys.cloud/

Note You need to log in before you can comment on or make changes to this bug.