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

On Sun, Aug 2, 2026 at 2:34=E2=80=AFAM Marco Giunta <[email protected]=
t> 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] =3D {
>                 .type =3D HDA_FIXUP_FUNC,
>                 .v.func =3D alc287_fixup_legion_16iax10h_aw88399,
>                 .chained =3D true,
>                 .chain_id =3D 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 wron=
g
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 b=
y
> 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