I have an HP Spectre x360 2-in-1 Laptop 16-aa0xxx that mostly works fine on Linux. Sound comes out of the speakers, the mute keys actually mute things, but the little LEDs in those keys never lit up. That annoyed me enough to go poking around in the kernel, and somehow that turned into my first upstream patch.

The key events showed up in userspace like you’d expect, so the keys and the input side were fine. The LED isn’t wired to the key directly anyway; the audio driver decides when to light it based on mute state. So whatever was broken lived in the kernel, in how the driver handles this particular board.

Finding the bug

Laptop audio quirks for Realtek HD-Audio codecs live in a giant table in sound/hda/codecs/realtek/alc269.c. The kernel looks at your PCI vendor/subsystem ID and picks a named “fixup” from that table.

You can grab the ID with:

cat /sys/class/sound/hwC0D0/subsystem_id
# or
lspci -nn | grep -i audio

Mine is 0x103c:0x8c17 (HP is 0x103c, board is 0x8c17). There’s also a neighboring 0x8c16 for what looks like the same Spectre family.

Grepping the quirk table:

SND_PCI_QUIRK(0x103c, 0x8c16, "HP Spectre x360 2-in-1 Laptop 16-aa0xxx",
              ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX),
SND_PCI_QUIRK(0x103c, 0x8c17, "HP Spectre 16",
              ALC287_FIXUP_CS35L41_I2C_2),

Same laptop family, off-by-one in the subsystem ID, completely different fixups.

ALC287_FIXUP_CS35L41_I2C_2 barely does anything. It just sets up the two CS35L41 smart amps over I2C:

[ALC287_FIXUP_CS35L41_I2C_2] = {
    .type = HDA_FIXUP_FUNC,
    .v.func = cs35l41_fixup_i2c_two,
},

The ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX path does the amp setup too, but it also wires up the mute LEDs. The interesting bit is at the end of the model-specific function:

cs35l41_fixup_i2c_two(codec, fix, action);
alc245_fixup_hp_mute_led_coefbit(codec, fix, action);
alc245_fixup_hp_gpio_led(codec, fix, action);

So 0x8c16 gets pin fixes, amp init, and the mute LED hooks. 0x8c17 only gets the amps. Which is exactly the bug I was hitting: sound works, LEDs don’t.

The patch

I pointed 0x8c17 at the same Spectre fixup as 0x8c16 and fixed the product string while I was there:

-	SND_PCI_QUIRK(0x103c, 0x8c17, "HP Spectre 16", ALC287_FIXUP_CS35L41_I2C_2),
+	SND_PCI_QUIRK(0x103c, 0x8c17, "HP Spectre x360 2-in-1 Laptop 16-aa0xxx",
+		      ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX),

Rebuilt, rebooted, mute LEDs lit up. Speakers still worked. I didn’t need any new model-specific code; the existing 16-aa0xxx fixup already knew how to drive this board.

Sending it upstream

Kernel audio patches go through the ALSA maintainers over email, not GitHub PRs.

Roughly:

  1. Clone torvalds/linux (or the ALSA sound tree), branch, commit with the usual subject prefix.
  2. scripts/checkpatch.pl -g HEAD
  3. scripts/get_maintainer.pl -f sound/hda/codecs/realtek/alc269.c for who to mail
  4. git send-email to those people plus linux-sound@vger.kernel.org

Commit message:

ALSA: hda/realtek: Enable mute LEDs on HP Spectre x360 16-aa0xxx

The HP Spectre x360 2-in-1 Laptop 16-aa0xxx with PCI subsystem ID
0x103c:0x8c17 only gets the CS35L41 amplifier setup from
ALC287_FIXUP_CS35L41_I2C_2, so the speaker-mute and mic-mute keyboard
LEDs do not work.

Use ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX like subsystem ID 0x8c16 so
the mute LEDs work.

Tested on HP Spectre x360 2-in-1 Laptop 16-aa0xxx.

Signed-off-by: Shang En Sim <sim@shangen.org>

I sent it on 2026-08-06. Next morning Takashi Iwai replied:

Applied to for-next branch now. Thanks.

The commit, bfcdc1c0e, sits in sound/for-next and has already made it into linux-next. It hasn’t reached Torvalds’ master yet.

A lot of “my laptop is weird on Linux” stuff is just a missing or wrong quirk table entry. If you own the hardware, you can usually verify and fix it yourself.