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

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