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

On Mon, 03 Aug 2026 11:27:48 +0200,
Pengyu Ma wrote:
> 
> On Sun, Aug 2, 2026 at 2:34 AM Marco Giunta <[email protected]> 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