[BUG] No audio from headphone jack on Conexant SN6140 + Meteor/Arrow Lake (Core Ultra 200H/200V), unlisted PCI SSID 17aa:0000

[hrydi]

Describe the bug

On a Lenovo laptop (PCI Subsystem ID 17aa:0000 — not matched by any existing quirk/fixup table) with an Intel "Core Ultra 200H/200V" series processor (Meteor Lake / Arrow Lake) and a Conexant SN6140 codec, the internal speaker works correctly, but the 3.5mm headphone jack produces no audio at all. This happens despite every software-level indicator — jack presence detection, mixer playback switches/volumes, EAPD, and pin control registers — reporting a fully enabled and unmuted state. The headphone jack works correctly under Windows on the same physical hardware (dual boot), which rules out a hardware fault.

What I've tried to diagnose or work around this:

• Confirmed jack presence detection is active and reports "plugged in" correctly (amixer Headphone Jack control = on) both under SOF and under the legacy snd-hda-intel driver.
• Confirmed Headphone Playback Switch = on (both channels) and Headphone Playback Volume = max (74/74), verified via pure ALSA state dump with PipeWire fully stopped (systemctl --user stop pipewire pipewire-pulse wireplumber), so this is not a PipeWire/WirePlumber routing or profile issue.
• Inspected /proc/asound/card0/codec#0: node 0x16 (headphone pin) shows Pincap OUT HP EAPD Detect, EAPD 0x2: EAPD (enabled), Pin-ctls: 0xc0: OUT HP (enabled), Unsolicited: tag=02, enabled=1, Power: setting=D0, actual=D0 — all consistent with a correctly enabled output pin.
• Manually forced EAPD on via hda-verb /dev/snd/hwC0D0 0x16 0x70c 0x2 — no change, still silent.
• Tried bypassing SOF entirely by forcing the legacy HDA driver (snd_intel_dspcfg.dsp_driver=1), confirmed via /proc/asound/cards showing HDA Intel PCH / driver snd_hda_intel instead of sof-hda-dsp. Same autoconfig (blank fixup for SSID 17aa:0000), same jack-detect/mixer state as under SOF. Headphone output was still completely silent under the legacy driver (tested via both pw-play and raw speaker-test -D hw:0,0 with PipeWire stopped), while the speaker continued to work correctly in this mode too.
• Ran speaker-test -D hw:0,0 -c 2 -t wav directly against ALSA with headphones plugged in and the "Headphones" output profile/pin selected — no audible test tone in either SOF or legacy mode.

Given that jack detection, EAPD, pin control, and playback switch/volume all report a fully enabled state under both stacks, and headphone output still produces no audio in either case, this looks like the physical headphone amplifier on this hardware may be gated by a mechanism outside the standard HDA verb set (e.g. a GPIO or embedded-controller toggle) that only the vendor's Windows driver currently knows how to activate — or a machine-specific quirk/topology entry is needed for this exact codec + platform combination (PCI SSID 17aa:0000 is unlisted).

To Reproduce

1. Boot Fedora 44 (KDE Plasma) on the affected laptop.
2. Play audio with the internal speaker selected as output — works fine.
3. Plug in wired headphones (3.5mm jack). amixer confirms Headphone Jack = on.
4. In KDE's Audio Volume applet (PipeWire/WirePlumber), select the "Headphones" output profile (Speaker and Headphones are exposed as two separate, mutually exclusive profiles rather than ports within a single auto-switching profile).
5. Play audio, or run speaker-test -D hw:0,0 -c 2 -t wav directly — no sound is produced from the headphones.

Reproduction Rate

All the time (100%), both with the SOF driver stack and with the legacy snd-hda-intel driver forced via dsp_driver=1. Speaker output is unaffected and works reliably in both cases.

Expected behavior

Audio should play through the headphones when they are plugged in and selected as the active output, matching the behavior already confirmed working under Windows on the same hardware.

Impact

Showstopper for headphone/wired-audio use on this laptop under Linux; internal speaker remains usable.

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: Fedora kernel 7.1.12-200.fc44.x86_64 (upstream commit hash unknown — happy to provide cat /proc/version / build info if useful)
   • SOF: firmware version 2.14.1.1 (alsa-sof-firmware-2025.12.2-1.fc44.noarch)
2. Name of the topology file
   • Topology: intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
3. Name of the platform(s) on which the bug is observed.
   • Platform: Intel Core Ultra 200H/200V series (Meteor Lake/Arrow Lake), sof-audio-pci-intel-mtl, machine driver skl_hda_dsp_generic, codec Conexant SN6140, PCI Subsystem ID 17aa:0000 (Lenovo, unlisted)

Screenshots or console output

dmesg codec autoconfig (identical under both SOF and legacy driver, only blank fixup differs from a laptop with a matched quirk):

snd_hda_codec_conexant hdaudioC0D0: SN6140: BIOS auto-probing.
snd_hda_codec_conexant hdaudioC0D0: SN6140: picked fixup  for PCI SSID 17aa:0000
snd_hda_codec_conexant hdaudioC0D0: autoconfig for SN6140: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
snd_hda_codec_conexant hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
snd_hda_codec_conexant hdaudioC0D0:    hp_outs=1 (0x16/0x0/0x0/0x0/0x0)
snd_hda_codec_conexant hdaudioC0D0:    mono: mono_out=0x0
snd_hda_codec_conexant hdaudioC0D0:    inputs:
snd_hda_codec_conexant hdaudioC0D0:      Mic=0x19

SOF firmware/topology load (from journalctl -b):

sof-audio-pci-intel-mtl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
sof-audio-pci-intel-mtl 0000:00:1f.3: hda codecs found, mask 5
sof-audio-pci-intel-mtl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware file:     intel/sof-ipc4/arl/sof-arl.ri
sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware lib path: intel/sof-ipc4-lib/arl
sof-audio-pci-intel-mtl 0000:00:1f.3: Topology file:     intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
sof-audio-pci-intel-mtl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.14.1.1
sof-audio-pci-intel-mtl 0000:00:1f.3: Booted firmware version: 2.14.1.1
sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1

Jack detection (amixer -c0 contents, identical result under SOF and legacy driver):

numid=14,iface=CARD,name='Headphone Jack'
  ; type=BOOLEAN,access=r-------,values=1
  : values=on
numid=13,iface=CARD,name='Mic Jack'
  : values=on
numid=15,iface=CARD,name='Speaker Phantom Jack'
  : values=on

Headphone mixer state (pure ALSA dump via alsactl store, PipeWire stopped):

name 'Headphone Playback Volume'
  value.0 74
  value.1 74
name 'Headphone Playback Switch'
  value.0 true
  value.1 true
name 'Headphone Jack'
  value true

Codec pin/widget dump, /proc/asound/card0/codec#0, node 0x16 (headphone pin) and its selected DAC:

Node 0x16 [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x0001001c: OUT HP EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x03211040: [Jack] HP Out at Ext Left
    Conn = 1/8, Color = Black
    DefAssociation = 0x4, Sequence = 0x0
  Pin-ctls: 0xc0: OUT HP
  Unsolicited: tag=02, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x10* 0x11

Node 0x10 [Audio Output] wcaps 0xc1d: Stereo Amp-Out R/L
  Control: name="Headphone Playback Volume"
  Control: name="Headphone Playback Switch"
  Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1
  Amp-Out vals:  [0x4a 0x4a]
  Converter: stream=0, channel=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0

Note: Converter: stream=0 was captured while idle; not yet re-confirmed with a stream actively assigned during playback — happy to re-test and provide that if useful.

For comparison, node 0x17 (speaker pin, working correctly):

Node 0x17 [Pin Complex] wcaps 0x400501: Stereo
  Pincap 0x00010010: OUT EAPD
  EAPD 0x2: EAPD
  Pin Default 0x91170110: [Fixed] Speaker at Int Rear
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:
  Power states:  D0 D1 D2 D3 EPSS

Full dmesg, full journalctl -b, complete /proc/asound/card0/codec#0 dump (all nodes), and sof-logger output can be attached/provided on request — I have not yet captured a sof-logger trace and can do so if pointed to the recommended invocation for this firmware version.