[PATCH 1/3] ALSA: hda/realtek: Use AW88399 I2C fixup chain on Legion machines

[PATCH 1/3] ALSA: hda/realtek: Use AW88399 I2C fixup chain on Legion machines

[Aaron Ma]

Six Lenovo Legion codec SSIDs use an ALC287 with two AW88399 amplifiers
registered through AWDZ8399. Bind them to ALC287_FIXUP_AW88399_I2C_2 and
chain the existing microphone, headset, jack, and DAC-routing fixups.
Disable auto-mic switching to preserve explicit internal-mic selection.

Drop the dedicated Legion fixup and its redundant 0x1d override. Firmware
already marks 0x1d as an unused modem-line pin, which the parser ignores;
overriding it only produces a legacy SKU warning. Retain the existing
Lenovo routing for quad-speaker output.

Signed-off-by: Aaron Ma <mapengyu@gmail.com>
---
 sound/hda/codecs/realtek/alc269.c | 62 +++++++++++++------------------
 1 file changed, 26 insertions(+), 36 deletions(-)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index f7877127e0e49..2e3f7f1b52782 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -3270,32 +3270,14 @@ static void find_cirrus_companion_amps(struct hda_codec *cdc)
 
 static void aw88399_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup *fix, int action)
 {
+	struct alc_spec *spec = cdc->spec;
+
+	if (action == HDA_FIXUP_ACT_PRE_PROBE)
+		spec->gen.suppress_auto_mic = 1;
+
 	comp_generic_fixup(cdc, action, "i2c", "AWDZ8399", "-%s:00-aw88399-hda.%d", 2);
 }
 
-static void alc287_fixup_legion_16iax10h_aw88399(struct hda_codec *codec,
-						 const struct hda_fixup *fix, int action)
-{
-	static const struct hda_pintbl pincfgs[] = {
-		{ 0x1d, 0x411111f0 }, /* unused bogus pin */
-		{ }
-	};
-
-	/*
-	 * Force DAC 0x02 for the bass speaker 0x17, as the default 0x06 lacks volume controls.
-	 */
-	static const hda_nid_t conn[] = { 0x02 };
-
-	alc269_fixup_limit_int_mic_boost(codec, fix, action);
-
-	switch (action) {
-	case HDA_FIXUP_ACT_PRE_PROBE:
-		snd_hda_apply_pincfgs(codec, pincfgs);
-		snd_hda_override_conn_list(codec, 0x17, ARRAY_SIZE(conn), conn);
-		break;
-	}
-}
-
 static void cs35l41_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup *fix, int action)
 {
 	comp_generic_fixup(cdc, action, "i2c", "CSC3551", "-%s:00-cs35l41-hda.%d", 2);
@@ -4267,7 +4249,8 @@ enum {
 	ALC274_FIXUP_HP_89E9_GPIO,
 	ALC274_FIXUP_HP_VERBS,
 	ALC287_FIXUP_AW88399_I2C_2,
-	ALC287_FIXUP_LENOVO_LEGION_AW88399,
+	ALC287_FIXUP_AW88399_LIMIT_INT_MIC_BOOST,
+	ALC287_FIXUP_AW88399_HEADSET_MIC,
 };
 
 /* A special fixup for Lenovo C940 and Yoga Duet 7;
@@ -6967,12 +6950,20 @@ static const struct hda_fixup alc269_fixups[] = {
 	[ALC287_FIXUP_AW88399_I2C_2] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = aw88399_fixup_i2c_two,
-	},
-	[ALC287_FIXUP_LENOVO_LEGION_AW88399] = {
-		.type = HDA_FIXUP_FUNC,
-		.v.func = alc287_fixup_legion_16iax10h_aw88399,
 		.chained = true,
-		.chain_id = ALC287_FIXUP_AW88399_I2C_2,
+		.chain_id = ALC287_FIXUP_AW88399_LIMIT_INT_MIC_BOOST,
+	},
+	[ALC287_FIXUP_AW88399_LIMIT_INT_MIC_BOOST] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc269_fixup_limit_int_mic_boost,
+		.chained = true,
+		.chain_id = ALC287_FIXUP_AW88399_HEADSET_MIC,
+	},
+	[ALC287_FIXUP_AW88399_HEADSET_MIC] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc_fixup_headset_mode_no_hp_mic,
+		.chained = true,
+		.chain_id = ALC287_FIXUP_LENOVO_XPAD_HEADSET_JACK,
 	},
 };
 
@@ -8037,8 +8028,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	/* Legion R9000P ADR10 shares PCI SSID 17aa:38bb with Yoga S780-14.5 Air AMD quad AAC;
 	 * use codec SSID to distinguish them
 	 */
-	HDA_CODEC_QUIRK(0x17aa, 0x3927, "Legion R9000P ADR10", ALC287_FIXUP_LENOVO_LEGION_AW88399),
-	HDA_CODEC_QUIRK(0x17aa, 0x3928, "Legion R9000P ADR10", ALC287_FIXUP_LENOVO_LEGION_AW88399),
+	HDA_CODEC_QUIRK(0x17aa, 0x3927, "Legion R9000P ADR10", ALC287_FIXUP_AW88399_I2C_2),
+	HDA_CODEC_QUIRK(0x17aa, 0x3928, "Legion R9000P ADR10", ALC287_FIXUP_AW88399_I2C_2),
 	SND_PCI_QUIRK(0x17aa, 0x38bb, "Yoga S780-14.5 Air AMD quad AAC", ALC287_FIXUP_TAS2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x38be, "Yoga S980-14.5 proX YC Dual", ALC287_FIXUP_TAS2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x38bf, "Yoga S980-14.5 proX LX Dual", ALC287_FIXUP_TAS2781_I2C),
@@ -8066,8 +8057,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x38fc, "Lenovo Yoga Pro 7 15ASH11", ALC287_FIXUP_LENOVO_YOGA_PRO7),
 	SND_PCI_QUIRK(0x17aa, 0x38fd, "ThinkBook plus Gen5 Hybrid", ALC287_FIXUP_TAS2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
-	HDA_CODEC_QUIRK(0x17aa, 0x3906, "Legion Pro 7i 16IAX10H / Y9000P IAX10", ALC287_FIXUP_LENOVO_LEGION_AW88399),
-	HDA_CODEC_QUIRK(0x17aa, 0x3907, "Legion Pro 7i 16IAX10H / Y9000P IAX10", ALC287_FIXUP_LENOVO_LEGION_AW88399),
+	HDA_CODEC_QUIRK(0x17aa, 0x3906, "Legion Pro 7i 16IAX10H / Y9000P IAX10", ALC287_FIXUP_AW88399_I2C_2),
+	HDA_CODEC_QUIRK(0x17aa, 0x3907, "Legion Pro 7i 16IAX10H / Y9000P IAX10", ALC287_FIXUP_AW88399_I2C_2),
 	SND_PCI_QUIRK(0x17aa, 0x390d, "Lenovo Yoga Pro 7 14ASP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
 	SND_PCI_QUIRK(0x17aa, 0x3911, "Lenovo Yoga Pro 7 14IAH10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
 	SND_PCI_QUIRK(0x17aa, 0x3912, "Lenovo Xiaoxin 14 GT", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
@@ -8077,8 +8068,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x3920, "Yoga S990-16 pro Quad VECO Quad", ALC287_FIXUP_TXNW2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x3929, "Thinkbook 13x Gen 5", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
 	SND_PCI_QUIRK(0x17aa, 0x392b, "Thinkbook 13x Gen 5", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
-	HDA_CODEC_QUIRK(0x17aa, 0x3938, "Legion Pro 7 16AFR10H", ALC287_FIXUP_LENOVO_LEGION_AW88399),
-	HDA_CODEC_QUIRK(0x17aa, 0x3939, "Legion Pro 7 16AFR10H", ALC287_FIXUP_LENOVO_LEGION_AW88399),
+	HDA_CODEC_QUIRK(0x17aa, 0x3938, "Legion Pro 7 16AFR10H", ALC287_FIXUP_AW88399_I2C_2),
+	HDA_CODEC_QUIRK(0x17aa, 0x3939, "Legion Pro 7 16AFR10H", ALC287_FIXUP_AW88399_I2C_2),
 	SND_PCI_QUIRK(0x17aa, 0x393e, "Lenovo ThinkBook 14 G8+ IPH", ALC287_FIXUP_LENOVO_XPAD_HEADSET_JACK),
 	HDA_CODEC_QUIRK(0x17aa, 0x394c, "Lenovo Yoga Slim 7 14AGP11", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
 	SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC),
@@ -8383,7 +8374,6 @@ static const struct hda_model_fixup alc269_fixup_models[] = {
 	{.id = ALC2XX_FIXUP_HEADSET_MIC, .name = "alc2xx-fixup-headset-mic"},
 	{.id = ALC245_FIXUP_BASS_HP_DAC, .name = "alc245-fixup-bass-hp-dac"},
 	{.id = ALC256_FIXUP_HONOR_MRB_XXX_M1020_AUDIO, .name = "alc256-honor-mrb-xxx-m1020-audio"},
-	{.id = ALC287_FIXUP_LENOVO_LEGION_AW88399, .name = "alc287-lenovo-legion-aw88399"},
 	{}
 };
 #define ALC225_STANDARD_PINS \
-- 
2.53.0

[PATCH 2/3] ALSA: hda/realtek: Use quad channel map for Legion AW88399 speakers

[Aaron Ma]

The Lenovo Legion machines pairing an ALC287 codec with two AW88399
smart amplifiers have four speaker channels. The second pair is
full-range rear, not an LFE channel, so the default mapping is wrong.

Advertise FL/FR/RL/RR quad channel maps on the playback stream so
4-channel streams are routed correctly.

Signed-off-by: Aaron Ma <mapengyu@gmail.com>
---
 sound/hda/codecs/realtek/alc269.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 2e3f7f1b52782..42fcdfe54225a 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -3268,6 +3268,15 @@ static void find_cirrus_companion_amps(struct hda_codec *cdc)
 	comp_generic_fixup(cdc, HDA_FIXUP_ACT_PRE_PROBE, bus, acpi_ids[i].hid, match, count);
 }
 
+static const struct snd_pcm_chmap_elem aw88399_pcm_quad_chmaps[] = {
+	{ .channels = 2,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+	{ .channels = 4,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR,
+		   SNDRV_CHMAP_RL, SNDRV_CHMAP_RR } },
+	{ }
+};
+
 static void aw88399_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup *fix, int action)
 {
 	struct alc_spec *spec = cdc->spec;
@@ -3276,6 +3285,10 @@ static void aw88399_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup
 		spec->gen.suppress_auto_mic = 1;
 
 	comp_generic_fixup(cdc, action, "i2c", "AWDZ8399", "-%s:00-aw88399-hda.%d", 2);
+	/* the second speaker pair is full-range rear, not LFE */
+	if (action == HDA_FIXUP_ACT_BUILD)
+		spec->gen.pcm_rec[0]->stream[SNDRV_PCM_STREAM_PLAYBACK].chmap =
+			aw88399_pcm_quad_chmaps;
 }
 
 static void cs35l41_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup *fix, int action)
-- 
2.53.0

[PATCH 3/3] ALSA: hda/realtek: Rename headphone jack kcontrol on Legion machines

[Aaron Ma]

The Lenovo Legion machines pairing an ALC287 codec with two AW88399
smart amplifiers report the headphone and headset functions in the
same jack group. With a kcontrol named "Headphone Jack", GNOME
treats them as two candidate devices of one port group and prompts
the user to choose between them on every plug event.

Rename the control to "Dock Headphone Jack", following the ThinkPad
naming convention, so the jack is presented as a distinct port and no
selection dialog appears.

Signed-off-by: Aaron Ma <mapengyu@gmail.com>
---
 sound/hda/codecs/realtek/alc269.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 42fcdfe54225a..83bb74c94b785 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -3280,15 +3280,26 @@ static const struct snd_pcm_chmap_elem aw88399_pcm_quad_chmaps[] = {
 static void aw88399_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup *fix, int action)
 {
 	struct alc_spec *spec = cdc->spec;
+	struct snd_ctl_elem_id id = {
+		.iface = SNDRV_CTL_ELEM_IFACE_CARD,
+	};
+	struct snd_kcontrol *kctl;
 
 	if (action == HDA_FIXUP_ACT_PRE_PROBE)
 		spec->gen.suppress_auto_mic = 1;
 
 	comp_generic_fixup(cdc, action, "i2c", "AWDZ8399", "-%s:00-aw88399-hda.%d", 2);
 	/* the second speaker pair is full-range rear, not LFE */
-	if (action == HDA_FIXUP_ACT_BUILD)
+	if (action == HDA_FIXUP_ACT_BUILD) {
 		spec->gen.pcm_rec[0]->stream[SNDRV_PCM_STREAM_PLAYBACK].chmap =
 			aw88399_pcm_quad_chmaps;
+
+		strscpy(id.name, "Headphone Jack", sizeof(id.name));
+		kctl = snd_ctl_find_id(cdc->card, &id);
+		if (kctl)
+			snd_ctl_rename(cdc->card, kctl,
+				       "Dock Headphone Jack");
+	}
 }
 
 static void cs35l41_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup *fix, int action)
-- 
2.53.0

Re: [PATCH 1/3] ALSA: hda/realtek: Use AW88399 I2C fixup chain on Legion machines

[Marco Giunta]

Hi Aaron,

I have serious concerns about this series. I addressed some of the
points below in my previous reply to your review of my v2 patch 3,
but I will reiterate them here for the benefit of everyone else.

* Patch 1: Default DAC routing

> Retain the existing Lenovo routing

Previously, you stated that the default 0x17->0x03 routing didn't need
to be changed, but this is NOT the default on these Legions, and in fact
I think this is just a misunderstanding based on the R9000P.
That laptop shares the PCI SSID 17aa:38bb with the Yoga S780 entry,
which chains through to alc285_fixup_thinkpad_x1_gen7 and sets:

    static const hda_nid_t preferred_pairs[] = {
        0x14, 0x02, 0x17, 0x03, 0x21, 0x03, 0
    };

This is the Yoga/ThinkPad routing, not the Legion's. The actual
hardware default for pin 0x17 on all known Legion models is DAC 0x06.
This can be readily verified on a Legion model that boots without the PCI
SSID collision, and I can personally attest it's the default on my
Pro 7 16AFR10H (codec SSID 17aa:3938).
The HDA_CODEC_QUIRK entries in the current code exist precisely
to prevent this collision by matching on codec SSID instead of
PCI SSID. It's not impossible that some hardware revisions already have
the 0x17->0x02 rerouting, but even if such laptops exist,
on all tested hardware the default routing is the incorrect 0x17->0x06.

Also, your series calls alc285_fixup_thinkpad_x1_gen7 via
ALC287_FIXUP_LENOVO_XPAD_HEADSET_JACK, so the fact that volume controls
work at all under your patch is a consequence of the fact that you, too,
override the default routing (but with 0x17->0x03, which is the DAC
usually reserved for headphones on these realtek codecs).

In general, not having a DAC override for pin 0x17 WILL break volume
controls on all supported Legion models. DAC 0x06 has no volume amplifier;
without the override, users get binary 0/100% volume.
That the 0x17->0x02 fix works and is indeed needed has been verified by
every tester across all three supported models, confirmed by the Windows
driver codec dump which selects DAC 0x02 for both 0x14 and 0x17, and is
consistent with dozens of existing alc269.c entries which perform
the same override (with comments clearly stating that this is done to fix
broken volume controls). Also, many of these quirks share a single DAC
between tweeters and woofers (typically 0x02 for both 0x14 and 0x17)
without issue, meaning the currently accepted solution doesn't appear
to be particularly problematic.

Regarding the 0x1d pincfg override: I don't disagree that in practice
this makes no difference, and I'm happy to have it removed if a maintainer
asks. This line was simply added to ensure we match exactly the pincfg of
the official Windows driver.

* Patch 1, 2 and 3: architectural concerns

ALC287_FIXUP_AW88399_I2C_2 is the base fixup that registers the
AW88399 amplifiers, by binding to the i2c devices created by the SMI
driver. It should remain generic and applicable to any machine using this
chip. Stuffing Legion-specific behavior (suppress_auto_mic, headset mode,
jack renaming, channel maps) directly into this function means any future
non-Legion machine using AW88399 inherits all of it.

The current design intentionally separates the two new quirks:
ALC287_FIXUP_AW88399_I2C_2 handles generic amp registration,
while ALC287_FIXUP_LENOVO_LEGION_AW88399 chains to it and adds
model-specific fixups. This is the same pattern used e.g. by the CS35L41
driver quirks, which have a generic cs35l41_fixup_i2c_two and separate
per-vendor fixup entries that chain to it.

Additionally, replacing a single self-contained ~20-line function with
a chain of three separate fixup entries
(ALC287_FIXUP_AW88399_LIMIT_INT_MIC_BOOST ->
ALC287_FIXUP_AW88399_HEADSET_MIC ->
ALC287_FIXUP_LENOVO_XPAD_HEADSET_JACK), each with its own chains,
makes the code harder to follow, forcing a reader to chase through the
fixup array to understand what the chain does. There's no code reuse
benefit either, since these new chained entries aren't individually
shared with other devices.

Patch 1 also removes the "alc287-lenovo-legion-aw88399" entry from
alc269_fixup_models[]. This entry allows users to force the Legion fixup
via the model= module boot parameter, which makes testing the new driver
much easier on new Legion models that may need it. Without it, users of
unsupported models have no way to easily verify whether our driver
applies to their hardware, and are instead forced to recompile the kernel.

* Patch 2: quad channel maps

I tested both patches on my 16AFR10H with music playback.

* With a 2.0 profile: both patches work correctly; tweeters and woofers
 play together as expected.
* With a 4.0 profile and my patch: music is fully silent (both tweeters
  and woofers).
* With a 4.0 profile and your patch: music plays through the
  tweeters only, woofers silent.
This is technically an improvement over full silence, but it reproduces
the exact broken state that motivated this entire driver effort: weak,
tinny audio from tweeters with no bass.

Even if the mapping were inverted so that only woofers played under 4.0,
it would still be wrong; bass-only audio without tweeters is equally as
broken.

In general, the only meaningful configuration for this hardware is stereo
2.0, where tweeters and woofers play the same signal together.
There is no useful way to split them into separate channels, because
they are not separate channels -- they are frequency-divided reproductions
of the same stereo signal. The bogus 4.0 profiles are an artifact of the
HDA parser, to be suppressed at userspace level via alsa-ucm-conf
(or simply ignored in practice), not by adding channel maps at the
realtek quirk-level. As such, I'm not convinced this patch is needed
in practice.

Also, as far as I can tell, there is no upstream precedent for mapping
a laptop's tweeter/woofer pairs as 4.0 surround channels.

* Patch 3: headphone jack rename

These laptops don't have docks. Renaming "Headphone Jack" to
"Dock Headphone Jack" is semantically incorrect, and I'm not convinced
the Thinkpad precedent applies here.
Regarding the need for this change, if there is a GNOME prompt issue
on plug events, that should be addressed at the userspace level, not by
giving hardware a misleading name.
More generally, I'm not sure I understand what problem is being solved
by this patch, as no Legion user has ever reported any issue
related to headphones and mic switching. I can also personally attest no
such issues on my Fedora 44 KDE install on the 16AFR10H.

* Summary

This series modifies a well-tested and necessary DAC override,
adds surround channel maps for hardware that isn't surround,
renames a jack to work around a quirk specific to one desktop environment,
and mixes generic and model-specific fixups in ways that will affect
future devices, while making the code harder to read and to test on
new devices.
None of these changes have been tested by the testers who validated
the current code.

Based on data from our github repo, I can attest that the current
fixup chain has likely been used by at least ~250 people in the last
~4 months across multiple kernel versions (from 6.19.10 to present)
and distros (Fedora, Arch, Cachy, Debian, Ubuntu, Nobara),
with no reports of mic switching or headset detection issues, instead
reporting that the 0x17->0x02 override was able to remove the need for
the alsa-ucm-conf workaround that was previously used to fix broken
volume controls on this hardware. As such, I am a bit surprised by this
patch series, and I admit I'm probably misunderstanding something or
missing some important context.

If the suppress_auto_mic and headset mode changes address a real mic or
headset issue on these Legions which I'm currently misunderstanding
and didn't happen to hear about previously, I'm happy to have them
incorporated as a separate patch on top of the existing fixup chain,
while preserving the crucial DAC 0x02 override needed for working
volume controls. But I'd first like to better understand what problem
they solve, as no Legion user has reported mic switching or
headset detection issues.

May I ask, on what Legion model (with what codec SSID) did you test
these changes? Is there a bug report thread I may read to get
more context?

Best regards,
Marco

Re: [PATCH 1/3] ALSA: hda/realtek: Use AW88399 I2C fixup chain on Legion machines

[Pengyu Ma]

On Sat, Aug 1, 2026 at 8:56 PM Marco Giunta <marco_giunta@outlook.it> wrote:
>
> Hi Aaron,
>
> I have serious concerns about this series. I addressed some of the
> points below in my previous reply to your review of my v2 patch 3,
> but I will reiterate them here for the benefit of everyone else.
>
> * Patch 1: Default DAC routing
>
> > Retain the existing Lenovo routing
>
> Previously, you stated that the default 0x17->0x03 routing didn't need
> to be changed, but this is NOT the default on these Legions, and in fact
> I think this is just a misunderstanding based on the R9000P.
> That laptop shares the PCI SSID 17aa:38bb with the Yoga S780 entry,
> which chains through to alc285_fixup_thinkpad_x1_gen7 and sets:
>
>     static const hda_nid_t preferred_pairs[] = {
>         0x14, 0x02, 0x17, 0x03, 0x21, 0x03, 0
>     };
>
> This is the Yoga/ThinkPad routing, not the Legion's. The actual
> hardware default for pin 0x17 on all known Legion models is DAC 0x06.
> This can be readily verified on a Legion model that boots without the PCI
> SSID collision, and I can personally attest it's the default on my
> Pro 7 16AFR10H (codec SSID 17aa:3938).
> The HDA_CODEC_QUIRK entries in the current code exist precisely
> to prevent this collision by matching on codec SSID instead of
> PCI SSID. It's not impossible that some hardware revisions already have
> the 0x17->0x02 rerouting, but even if such laptops exist,
> on all tested hardware the default routing is the incorrect 0x17->0x06.
>
> Also, your series calls alc285_fixup_thinkpad_x1_gen7 via
> ALC287_FIXUP_LENOVO_XPAD_HEADSET_JACK, so the fact that volume controls
> work at all under your patch is a consequence of the fact that you, too,
> override the default routing (but with 0x17->0x03, which is the DAC
> usually reserved for headphones on these realtek codecs).
>
> In general, not having a DAC override for pin 0x17 WILL break volume
> controls on all supported Legion models. DAC 0x06 has no volume amplifier;
> without the override, users get binary 0/100% volume.
> That the 0x17->0x02 fix works and is indeed needed has been verified by
> every tester across all three supported models, confirmed by the Windows
> driver codec dump which selects DAC 0x02 for both 0x14 and 0x17, and is
> consistent with dozens of existing alc269.c entries which perform
> the same override (with comments clearly stating that this is done to fix
> broken volume controls). Also, many of these quirks share a single DAC
> between tweeters and woofers (typically 0x02 for both 0x14 and 0x17)
> without issue, meaning the currently accepted solution doesn't appear
> to be particularly problematic.
>

DAC 0x03 is intentional. The hardware-default DAC 0x06 has no Amp-Out
volume control, while 0x03 has the same volume amplifier as 0x02 and
provides a separate stereo converter for the bottom pair. In 2-channel
mode, 0x02 and 0x03 both receive FL/FR. In 4-channel mode, generic HDA
assigns FL/FR to 0x02 and channels 3/4 to 0x03.

Your quirk forcing 0x17 to 0x02 breaks FL/FR in 4-channel mode.

> Regarding the 0x1d pincfg override: I don't disagree that in practice
> this makes no difference, and I'm happy to have it removed if a maintainer
> asks. This line was simply added to ensure we match exactly the pincfg of
> the official Windows driver.
>
> * Patch 1, 2 and 3: architectural concerns
>
> ALC287_FIXUP_AW88399_I2C_2 is the base fixup that registers the
> AW88399 amplifiers, by binding to the i2c devices created by the SMI
> driver. It should remain generic and applicable to any machine using this
> chip. Stuffing Legion-specific behavior (suppress_auto_mic, headset mode,
> jack renaming, channel maps) directly into this function means any future
> non-Legion machine using AW88399 inherits all of it.
>
> The current design intentionally separates the two new quirks:
> ALC287_FIXUP_AW88399_I2C_2 handles generic amp registration,
> while ALC287_FIXUP_LENOVO_LEGION_AW88399 chains to it and adds
> model-specific fixups. This is the same pattern used e.g. by the CS35L41
> driver quirks, which have a generic cs35l41_fixup_i2c_two and separate
> per-vendor fixup entries that chain to it.
>
> Additionally, replacing a single self-contained ~20-line function with
> a chain of three separate fixup entries
> (ALC287_FIXUP_AW88399_LIMIT_INT_MIC_BOOST ->
> ALC287_FIXUP_AW88399_HEADSET_MIC ->
> ALC287_FIXUP_LENOVO_XPAD_HEADSET_JACK), each with its own chains,
> makes the code harder to follow, forcing a reader to chase through the
> fixup array to understand what the chain does. There's no code reuse
> benefit either, since these new chained entries aren't individually
> shared with other devices.
>
> Patch 1 also removes the "alc287-lenovo-legion-aw88399" entry from
> alc269_fixup_models[]. This entry allows users to force the Legion fixup
> via the model= module boot parameter, which makes testing the new driver
> much easier on new Legion models that may need it. Without it, users of
> unsupported models have no way to easily verify whether our driver
> applies to their hardware, and are instead forced to recompile the kernel.
>
> * Patch 2: quad channel maps
>
> I tested both patches on my 16AFR10H with music playback.
>
> * With a 2.0 profile: both patches work correctly; tweeters and woofers
>  play together as expected.
> * With a 4.0 profile and my patch: music is fully silent (both tweeters
>   and woofers).
> * With a 4.0 profile and your patch: music plays through the
>   tweeters only, woofers silent.
> This is technically an improvement over full silence, but it reproduces
> the exact broken state that motivated this entire driver effort: weak,
> tinny audio from tweeters with no bass.
>

4.0 test used ordinary stereo music. That source contains
only FL/FR; the bottom pair is assigned channels 3/4, which remain
silent without upmixing.
Please test with `speaker-test -c4`.

> Even if the mapping were inverted so that only woofers played under 4.0,
> it would still be wrong; bass-only audio without tweeters is equally as
> broken.
>
> In general, the only meaningful configuration for this hardware is stereo
> 2.0, where tweeters and woofers play the same signal together.
> There is no useful way to split them into separate channels, because
> they are not separate channels -- they are frequency-divided reproductions
> of the same stereo signal. The bogus 4.0 profiles are an artifact of the
> HDA parser, to be suppressed at userspace level via alsa-ucm-conf
> (or simply ignored in practice), not by adding channel maps at the
> realtek quirk-level. As such, I'm not convinced this patch is needed
> in practice.
>
> Also, as far as I can tell, there is no upstream precedent for mapping
> a laptop's tweeter/woofer pairs as 4.0 surround channels.
>
> * Patch 3: headphone jack rename
>
> These laptops don't have docks. Renaming "Headphone Jack" to
> "Dock Headphone Jack" is semantically incorrect, and I'm not convinced
> the Thinkpad precedent applies here.
> Regarding the need for this change, if there is a GNOME prompt issue
> on plug events, that should be addressed at the userspace level, not by
> giving hardware a misleading name.
> More generally, I'm not sure I understand what problem is being solved
> by this patch, as no Legion user has ever reported any issue
> related to headphones and mic switching. I can also personally attest no
> such issues on my Fedora 44 KDE install on the 16AFR10H.
>

The root cause is the physical combo jack produces both logical
headphone and headset-mic presence signals.
So it should be renamed.

> * Summary
>
> This series modifies a well-tested and necessary DAC override,
> adds surround channel maps for hardware that isn't surround,
> renames a jack to work around a quirk specific to one desktop environment,
> and mixes generic and model-specific fixups in ways that will affect
> future devices, while making the code harder to read and to test on
> new devices.
> None of these changes have been tested by the testers who validated
> the current code.
>
> Based on data from our github repo, I can attest that the current
> fixup chain has likely been used by at least ~250 people in the last
> ~4 months across multiple kernel versions (from 6.19.10 to present)
> and distros (Fedora, Arch, Cachy, Debian, Ubuntu, Nobara),
> with no reports of mic switching or headset detection issues, instead
> reporting that the 0x17->0x02 override was able to remove the need for
> the alsa-ucm-conf workaround that was previously used to fix broken
> volume controls on this hardware. As such, I am a bit surprised by this
> patch series, and I admit I'm probably misunderstanding something or
> missing some important context.
>
> If the suppress_auto_mic and headset mode changes address a real mic or
> headset issue on these Legions which I'm currently misunderstanding
> and didn't happen to hear about previously, I'm happy to have them
> incorporated as a separate patch on top of the existing fixup chain,
> while preserving the crucial DAC 0x02 override needed for working
> volume controls. But I'd first like to better understand what problem
> they solve, as no Legion user has reported mic switching or
> headset detection issues.
>
> May I ask, on what Legion model (with what codec SSID) did you test
> these changes? Is there a bug report thread I may read to get
> more context?

Tested on 0x17aa3906
Analyzed alsa-info on 0x17aa3928.

The issues on current for-next branch are:
1, The 4.0 output is broken, no FL/FR. 4 speakers are visible on laptop.
2, when plugin headset, the mic is lock in headset mic, no switch to
Internal Mic.
3, when plugin headset with quirk of HEADSET, switch to Internal Mic,
but the input device is not valid.
4, Headset button is no response.
5, dmesg report "SKU not ready 0x411111f0"

Aaron

>
> Best regards,
> Marco

Re: [PATCH 1/3] ALSA: hda/realtek: Use AW88399 I2C fixup chain on Legion machines

[Marco Giunta]

Hi Aaron,

With the added context from your reply, I did some more testing of
your patches on my Pro 7 16AFR10H and I can confirm issues 2-4:

* With the current upstream code, plugging in a headset locks
  the mic to the headset input and marks the internal mic as
  unavailable/disconnected. Your mic fix resolves this; internal
  mic remains selectable and functional with a headset plugged in.

* Headset inline buttons (play/pause) work with your patches but not
  with the current code.

As for issue 5, it's true that the "SKU not ready" warning is caused
by the 0x1d pincfg override, which, though harmless in practice,
I'm happy to drop.

These are real issues that I missed because my testing focused on speaker
output and basic internal mic functionality, not headset behavior
specifically. Apologies for that, and thank you for catching them.

That said, I still believe the correct approach is to add these further
fixes to the existing Legion-specific chain rather than the generic
AW88399 function. Would you be open to preserving:

	[ALC287_FIXUP_LENOVO_LEGION_AW88399] = {
		.type = HDA_FIXUP_FUNC,
		.v.func = alc287_fixup_legion_16iax10h_aw88399,
		.chained = true,
		.chain_id = ALC287_FIXUP_AW88399_I2C_2,
	},

where alc287_fixup_legion_aw88399 now includes the DAC override,
mic boost limit, suppress_auto_mic, and headset mode setup in one
self-contained function? This preserves the generic/model-specific
separation while incorporating the new fixes.
More generally, I'd appreciate your thoughts on my comments on the
series' architecture, as this affects how any combined fix is structured.

Regarding the DAC routing: I understand 0x03 also has a volume amplifier,
but 0x02 matches the Windows driver configuration and is the established
pattern in alc269.c for this exact codec and pin. I still don't see a
practical benefit to routing 0x17 to 0x03 instead.

Regarding 4.0 channel maps: I remain unconvinced this is useful.
Even with speaker-test -c 4, all it achieves is the ability to play
tweeters and woofers independently, which no real-world content or
use case requires. The correct profile is stereo 2.0 with both driver
types playing together.

Regarding the jack rename: I understand the symptom: GNOME prompts the
user to choose between headphone and headset on every plug event.
I don't see this on KDE, which suggests it may be a
desktop-environment-specific behavior rather than a kernel issue.
Is there a reason this can't be handled at userspace level, rather than by
renaming the kernel control to something semantically incorrect for
hardware without a dock? Alternatively, can we find a different solution,
or more simply a different name?

I'm open to collaborating (e.g. with a Tested-by tag) on a v2 that
combines your headset/mic fixes with the existing DAC and
architectural approach. Would that work for you?

Best regards,
Marco

Re: [PATCH 1/3] ALSA: hda/realtek: Use AW88399 I2C fixup chain on Legion machines

[Pengyu Ma]

On Sun, Aug 2, 2026 at 2:34 AM Marco Giunta <marco_giunta@outlook.it> wrote:
>
> Hi Aaron,
>
> With the added context from your reply, I did some more testing of
> your patches on my Pro 7 16AFR10H and I can confirm issues 2-4:
>
> * With the current upstream code, plugging in a headset locks
>   the mic to the headset input and marks the internal mic as
>   unavailable/disconnected. Your mic fix resolves this; internal
>   mic remains selectable and functional with a headset plugged in.
>
> * Headset inline buttons (play/pause) work with your patches but not
>   with the current code.
>
> As for issue 5, it's true that the "SKU not ready" warning is caused
> by the 0x1d pincfg override, which, though harmless in practice,
> I'm happy to drop.
>
> These are real issues that I missed because my testing focused on speaker
> output and basic internal mic functionality, not headset behavior
> specifically. Apologies for that, and thank you for catching them.
>

Hi Marco,

Thanks for confirming the internal-mic selection and headset button fixes.


> That said, I still believe the correct approach is to add these further
> fixes to the existing Legion-specific chain rather than the generic
> AW88399 function. Would you be open to preserving:
>
>         [ALC287_FIXUP_LENOVO_LEGION_AW88399] = {
>                 .type = HDA_FIXUP_FUNC,
>                 .v.func = alc287_fixup_legion_16iax10h_aw88399,
>                 .chained = true,
>                 .chain_id = ALC287_FIXUP_AW88399_I2C_2,
>         },
>
> where alc287_fixup_legion_aw88399 now includes the DAC override,
> mic boost limit, suppress_auto_mic, and headset mode setup in one
> self-contained function? This preserves the generic/model-specific
> separation while incorporating the new fixes.
> More generally, I'd appreciate your thoughts on my comments on the
> series' architecture, as this affects how any combined fix is structured.
>

The current chain reuses existing Realtek helpers for the required mic,
headset, button, and DAC handling.  Its inherited XPad setup applies to
these laptops because they expose VPC2004.  The ThinkPad helper returns
when the ThinkPad ACPI nodes are absent.

> Regarding the DAC routing: I understand 0x03 also has a volume amplifier,
> but 0x02 matches the Windows driver configuration and is the established
> pattern in alc269.c for this exact codec and pin. I still don't see a
> practical benefit to routing 0x17 to 0x03 instead.
>
> Regarding 4.0 channel maps: I remain unconvinced this is useful.
> Even with speaker-test -c 4, all it achieves is the ability to play
> tweeters and woofers independently, which no real-world content or
> use case requires. The correct profile is stereo 2.0 with both driver
> types playing together.
>

Thus 0x02 receives FL/FR and 0x03 receives channels 3/4.  Forcing 0x17 to
0x02 collapses both speaker pins onto one DAC and gives the parser the wrong
output configuration.

The four speakers provide users a choice of output profiles.  For ordinary
stereo content, 2.0 is the preferred profile because both speaker pairs
receive FL/FR.

> Regarding the jack rename: I understand the symptom: GNOME prompts the
> user to choose between headphone and headset on every plug event.
> I don't see this on KDE, which suggests it may be a
> desktop-environment-specific behavior rather than a kernel issue.
> Is there a reason this can't be handled at userspace level, rather than by
> renaming the kernel control to something semantically incorrect for
> hardware without a dock? Alternatively, can we find a different solution,
> or more simply a different name?
>

The jack rename gives the headphone output a distinct ALSA jack identity so
PipeWire does not group it with the headset-mic route.

> I'm open to collaborating (e.g. with a Tested-by tag) on a v2 that
> combines your headset/mic fixes with the existing DAC and
> architectural approach. Would that work for you?
>

Let's wait for the maintainer's review to see if there is more.

Thanks,
Aaron

> Best regards,
> Marco

Re: [PATCH 1/3] ALSA: hda/realtek: Use AW88399 I2C fixup chain on Legion machines

[Takashi Iwai]

On Mon, 03 Aug 2026 11:27:48 +0200,
Pengyu Ma wrote:
> 
> On Sun, Aug 2, 2026 at 2:34 AM Marco Giunta <marco_giunta@outlook.it> wrote:
> >
> > Hi Aaron,
> >
> > With the added context from your reply, I did some more testing of
> > your patches on my Pro 7 16AFR10H and I can confirm issues 2-4:
> >
> > * With the current upstream code, plugging in a headset locks
> >   the mic to the headset input and marks the internal mic as
> >   unavailable/disconnected. Your mic fix resolves this; internal
> >   mic remains selectable and functional with a headset plugged in.
> >
> > * Headset inline buttons (play/pause) work with your patches but not
> >   with the current code.
> >
> > As for issue 5, it's true that the "SKU not ready" warning is caused
> > by the 0x1d pincfg override, which, though harmless in practice,
> > I'm happy to drop.
> >
> > These are real issues that I missed because my testing focused on speaker
> > output and basic internal mic functionality, not headset behavior
> > specifically. Apologies for that, and thank you for catching them.
> >
> 
> Hi Marco,
> 
> Thanks for confirming the internal-mic selection and headset button fixes.
> 
> 
> > That said, I still believe the correct approach is to add these further
> > fixes to the existing Legion-specific chain rather than the generic
> > AW88399 function. Would you be open to preserving:
> >
> >         [ALC287_FIXUP_LENOVO_LEGION_AW88399] = {
> >                 .type = HDA_FIXUP_FUNC,
> >                 .v.func = alc287_fixup_legion_16iax10h_aw88399,
> >                 .chained = true,
> >                 .chain_id = ALC287_FIXUP_AW88399_I2C_2,
> >         },
> >
> > where alc287_fixup_legion_aw88399 now includes the DAC override,
> > mic boost limit, suppress_auto_mic, and headset mode setup in one
> > self-contained function? This preserves the generic/model-specific
> > separation while incorporating the new fixes.
> > More generally, I'd appreciate your thoughts on my comments on the
> > series' architecture, as this affects how any combined fix is structured.
> >
> 
> The current chain reuses existing Realtek helpers for the required mic,
> headset, button, and DAC handling.  Its inherited XPad setup applies to
> these laptops because they expose VPC2004.  The ThinkPad helper returns
> when the ThinkPad ACPI nodes are absent.
> 
> > Regarding the DAC routing: I understand 0x03 also has a volume amplifier,
> > but 0x02 matches the Windows driver configuration and is the established
> > pattern in alc269.c for this exact codec and pin. I still don't see a
> > practical benefit to routing 0x17 to 0x03 instead.
> >
> > Regarding 4.0 channel maps: I remain unconvinced this is useful.
> > Even with speaker-test -c 4, all it achieves is the ability to play
> > tweeters and woofers independently, which no real-world content or
> > use case requires. The correct profile is stereo 2.0 with both driver
> > types playing together.
> >
> 
> Thus 0x02 receives FL/FR and 0x03 receives channels 3/4.  Forcing 0x17 to
> 0x02 collapses both speaker pins onto one DAC and gives the parser the wrong
> output configuration.
> 
> The four speakers provide users a choice of output profiles.  For ordinary
> stereo content, 2.0 is the preferred profile because both speaker pairs
> receive FL/FR.
> 
> > Regarding the jack rename: I understand the symptom: GNOME prompts the
> > user to choose between headphone and headset on every plug event.
> > I don't see this on KDE, which suggests it may be a
> > desktop-environment-specific behavior rather than a kernel issue.
> > Is there a reason this can't be handled at userspace level, rather than by
> > renaming the kernel control to something semantically incorrect for
> > hardware without a dock? Alternatively, can we find a different solution,
> > or more simply a different name?
> >
> 
> The jack rename gives the headphone output a distinct ALSA jack identity so
> PipeWire does not group it with the headset-mic route.
> 
> > I'm open to collaborating (e.g. with a Tested-by tag) on a v2 that
> > combines your headset/mic fixes with the existing DAC and
> > architectural approach. Would that work for you?
> >
> 
> Let's wait for the maintainer's review to see if there is more.

Not much from my side, but I just prefer receiving a solution that
satisfies both of you :)

So, if any, let's try a v2 patch set.  We still have a bit of time for
7.3 release.


thanks,

Takashi

Re: [PATCH 1/3] ALSA: hda/realtek: Use AW88399 I2C fixup chain on Legion machines

[Marco Giunta]

> Not much from my side, but I just prefer receiving a solution that
> satisfies both of you :)
>
> So, if any, let's try a v2 patch set.  We still have a bit of time for
> 7.3 release.

Here is my proposal for a compromise:

    [ALC287_FIXUP_AW88399_I2C_2] = {
        .type = HDA_FIXUP_FUNC,
        .v.func = aw88399_fixup_i2c_two,
    },
    [ALC287_FIXUP_LENOVO_LEGION_AW88399] = {
        .type = HDA_FIXUP_FUNC,
        .v.func = alc287_fixup_legion_16iax10h_aw88399,
        .chained = true,
        .chain_id = ALC287_FIXUP_AW88399_I2C_2,
    },

    static void aw88399_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup *fix, int action)
    {
        comp_generic_fixup(cdc, action, "i2c", "AWDZ8399", "-%s:00-aw88399-hda.%d", 2);
    }

    static void alc287_fixup_legion_16iax10h_aw88399(struct hda_codec *codec,
                            const struct hda_fixup *fix, int action)
    {
        struct alc_spec *spec = codec->spec;
        static const hda_nid_t conn[] = { 0x02 };

        alc269_fixup_limit_int_mic_boost(codec, fix, action);
        alc_fixup_headset_mode_no_hp_mic(codec, fix, action);
        alc_fixup_headset_jack(codec, fix, action);

        switch (action) {
        case HDA_FIXUP_ACT_PRE_PROBE:
            spec->gen.suppress_auto_mic = 1;
            snd_hda_override_conn_list(codec, 0x17, ARRAY_SIZE(conn), conn);
            break;
        }
    }

I believe this offers several advantages. In particular, it preserves
Aaron's fixes regarding working headset buttons and keeping the internal
mic available with headphones plugged in, while keeping a clean separation
between the generic aw88399 i2c fixup quirk and the Legion-specific stuff.
It also avoids picking up baggage from thinkpad/ideapad-specific quirks,
removes the SKU warning from the logs, and keeps the DAC rerouting explicit
rather than having it as the side-effect from deep within a long quirk chain.
Finally, it minimizes the number of quirks to be added overall, with no
redundancy, and avoids removing the "alc287-lenovo-legion-aw88399" entry
from alc269_fixup_models.

I'm happy to prepare and send the patch myself based on the above;
alternatively, I'm also fine with just offering whatever tag may be
relevant (Tested-by, Suggested-by, etc.).

Regarding the jack rename: given that I cannot reproduce that GNOME issue
on KDE Plasma, I remain unconvinced this isn't something to be dealt with
in userspace. That said, I'm not necessarily against implementing a kernel
level fix, but I'd like it to be a different fix. Whether that means
simply choosing a different, not misleading, name, or something else
altogether, I can't say right now.
Maybe Aaron can submit a follow-up patch on top of the above.

Regarding the quad channel map and DAC 0x03 rerouting: I still believe
that it's not useful to try to fix 4.0 support on an exclusively 2.0
laptop. The fact that there are 4 physical units on the laptop doesn't
mean they are supposed to be used independently: even when forcing 4.0
content, all this achieves is letting users use the tweeters independently,
which is the same broken state the aw88399 series was meant to fix in the
first place. Likewise for using the woofers without the tweeters.
I believe instead the proper fix is suppressing bogus 4.0 profiles at
userspace level (or more simply just ignoring them), as they don't
represent a meaningful configuration for this hardware.

Best regards,
Marco