Skip to content

[BUG] Headphone jack detection/functionality fail on HP OmniBook Ultra (Lunar Lake) - SSID 103C:8CDE #5757

Open

Description

@pavlo0909

Describe the bug
On the HP OmniBook Ultra Flip (Lunar Lake), the headphone jack (Realtek ALC245) fails to detect headphone insertion or output audio when using the SOF driver. While the internal speakers work, the headphone node remains in a disconnected state.

What have you tried to diagnose or workaround this issue?

  • Verified with dsp_driver=1 (Legacy HDA): Headphone jack works perfectly, but internal DMIC is lost.
    
  • Verified with default SOF driver: DMIC works, but Headphone jack is non-functional.
    
  • Tested with kernel 6.19.14 and SOF firmware 2.14.1.
    

To Reproduce

  • Boot with standard SOF driver.
    
  • Plug in headphones.
    
  • Check alsa-info or jack_retasking tools; Node 0x21 does not show "Jack Detect".
    

Reproduction Rate
100%

Expected behavior
Automatic switching to headphones on insertion and simultaneous support for the internal DMIC.

Impact
Showstopper. The laptop cannot be used for private listening or calls without a workaround that breaks the microphone.

Environment

Kernel: 6.19.14-200.fc43.x86_64

SOF Firmware Version: 2.14.1.1 (Build 362)

Topology: intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg

Platform: Lunar Lake (LNL)

Hardware ID: PCI SSID 103C:8CDE (Board Name: 8CDE)

Screenshots or console output
Relevant dmesg highlights:

[   28.082299] sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.14.1.1 (build 362)
[   28.100546] sof-audio-pci-intel-lnl 0000:00:1f.3: loading topology: intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
[   29.034638] snd_hda_codec_alc269 ehdaudio0D0: ALC245: picked fixup for PCI SSID 103c:8cde
[   29.089742] input: sof-hda-dsp Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input32

Amplifier Errors (potential I2C/ACPI conflict):

[   14.454016] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cannot add Reset/Speaker ID/SPI CS GPIO Mapping, _DSD already exists.
[   14.505248] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset

Codec Pin Status (Node 0x21) while plugged in:

Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Pincap 0x0001001c: OUT HP EAPD Detect
  Pin Default 0x03211020: [Jack] HP Out at Ext Left
  Pin-ctls: 0x00:
  Unsolicited: tag=01, enabled=1
  Connection: 1
     0x02

(Note: Pin-ctls is 0x00 even when plugged in, indicating the driver hasn't enabled the output.)

alsa-info.txt

Technical Analysis
Based on the alsa-info dump provided:

The kernel correctly identifies the board and picks a fixup: ALC245: picked fixup for PCI SSID 103c:8cde.

Despite an input device being created (input: sof-hda-dsp Headphone), Node 0x21 remains at Pin-ctls: 0x00 even with headphones plugged in.

The cs35l41-hda amplifiers are reporting _DSD mapping errors, which may suggest ACPI conflicts affecting the overall HDA link initialization.

Activity

  1. ujfalusi commented on May 8, 2026

    @ujfalusi
    Collaborator

    @pavlo0909, the HDA codec handling is outside and independent from SOF stack (in theory).
    Can you try to run this:

    watch "amixer -c0 contents | grep -A2 Jack"
    

    and plug, unplug (keep at least several seconds between) the jack and observe if either values in the list changes between on/off.

    If there is no change, can you try the same with legacy HDA stack?

    From these we can try to figure out how to proceed:
    legacy: values change, SOF: values don't change - this is hard to believe, but needs kernel fix
    legacy / SOF: values change - UCM/PW issue (legacy is not using UCM) and needs to be understood
    legacy / SOF: values don't change - UCM/PW issue (legacy is not using UCM) and needs to be understood - the jack state must be polled

    I would also do a quick search in https://github.com/alsa-project/alsa-ucm-conf/ if similar issue has been reported.

  2. pavlo0909 commented on May 8, 2026

    @pavlo0909
    Author

    @pavlo0909, the HDA codec handling is outside and independent from SOF stack (in theory). Can you try to run this:

    watch "amixer -c0 contents | grep -A2 Jack"
    

    and plug, unplug (keep at least several seconds between) the jack and observe if either values in the list changes between on/off.

    If there is no change, can you try the same with legacy HDA stack?

    From these we can try to figure out how to proceed: legacy: values change, SOF: values don't change - this is hard to believe, but needs kernel fix legacy / SOF: values change - UCM/PW issue (legacy is not using UCM) and needs to be understood legacy / SOF: values don't change - UCM/PW issue (legacy is not using UCM) and needs to be understood - the jack state must be polled

    I would also do a quick search in https://github.com/alsa-project/alsa-ucm-conf/ if similar issue has been reported.

    I ran
    watch "amixer -c0 contents | grep -A2 Jack"

    numid=22,iface=CARD,name='HDMI/DP,pcm=3 Jack'
      ; type=BOOLEAN,access=r-------,values=1
      : values=on
    numid=28,iface=CARD,name='HDMI/DP,pcm=4 Jack'
      ; type=BOOLEAN,access=r-------,values=1
      : values=off
    numid=34,iface=CARD,name='HDMI/DP,pcm=5 Jack'
      ; type=BOOLEAN,access=r-------,values=1
      : values=off
    numid=19,iface=CARD,name='Headphone Jack'
      ; type=BOOLEAN,access=r-------,values=1
      : values=on
    --
    numid=18,iface=CARD,name='Mic Jack'
      ; type=BOOLEAN,access=r-------,values=1
      : values=off
    --
    numid=20,iface=CARD,name='Speaker Front Phantom Jack'
      ; type=BOOLEAN,access=r-------,values=1
      : values=on
    numid=21,iface=CARD,name='Speaker Surround Phantom Jack'
      ; type=BOOLEAN,access=r-------,values=1
      : values=on
    

    Unplugged: numid=19,name='Headphone Jack' : values=off

    Plugged: numid=19,name='Headphone Jack' : values=on

  3. ujfalusi commented on May 8, 2026

    @ujfalusi
    Collaborator

    @pavlo0909, can you attach the output of alsaucm dump text and the output of spa-acp-tool lv for both the legacy and SOF case to the alsa-ucm issue?

    It is strange that the Mic Jack is not toggling, I think that UCM is monitoring that for the HS mic. You have 'Capture Switch' so it should be picking the right config.
    Can it be some issue with accessory type detection, hrm.

  4. pavlo0909 commented on May 8, 2026

    @pavlo0909
    Author

    @ujfalusi Thanks, I attached the outputs of those commands in the alsa-ucm issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcodecCodec HW or driver restriction

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions