[FEATURE] Samsung Galaxy Book4 Ultra NP960XGL: No speaker output (needs SOF PR #5616 / ALC298 MAX98390 quirk)

[fjoelnr]

Pre-flight checklist

• I have searched existing issues/PRs and this has not been requested before.
• I have read the Contributing Guidelines.

Request type

• New patch / patchset inclusion
• Kernel config change (enable/disable option)
• New kernel variant
• Scheduler tuning / addition
• Compiler / LTO / PGO optimization
• Security hardening
• Driver or hardware enablement
• Other

Summary

Hardware

• Model: Samsung Galaxy Book4 Ultra NP960XGL-XG1DE
• Audio codec: Realtek ALC298 (Subsystem ID: 0x144dc1d8)
• Speaker amps: 4x Maxim MAX98390 via I2C (addresses 0x38, 0x39, 0x3c, 0x3d)
• Kernel: 6.19.3-2-cachyos

Problem

Internal speakers produce no sound. Headphone jack and HDMI audio work fine.

Root cause

The snd_hda_codec_alc269 module does not contain a PCI quirk entry for SSID 0x144d:0xc1d8. Without this entry, the ALC298 codec does not register the MAX98390 amplifiers as HDA side-codec components, so the speaker amp chain is never initialized.

The fix exists in thesofproject/linux PR #5616:
thesofproject/linux#5616

It adds:

SND_PCI_QUIRK(0x144d, 0xc1d8, "Samsung Galaxy Book4 Ultra (NP960XGL)",
              ALC298_FIXUP_SAMSUNG_MAX98390_4_AMPS)

Current workaround state

• Installed community DKMS driver (Andycodeman/samsung-galaxy-book4-linux-fixes) ✅
• MAX98390 modules load and all 4 amps probe successfully ✅
• HDA component binding never completes — no sound ❌
• Missing: the SSID quirk in snd_hda_codec_alc269 ❌

Request

Please include the patch from SOF PR #5616 in the CachyOS 6.19 kernel patches.

Motivation / use case

Samsung Galaxy Book4 Ultra (NP960XGL-XG1DE) has 4x Maxim MAX98390 speaker amplifiers
connected via I2C to the Realtek ALC298 codec (SSID 0x144d:0xc1d8). Without the SSID
quirk in snd_hda_codec_alc269, the ALC298 never registers the MAX98390 amps as HDA
side-codec components, so internal speakers produce no sound at all. Headphones and
HDMI audio work fine. This affects all Linux users on this hardware.

Patch / upstream reference (if available)

thesofproject/linux#5616

Testing / benchmarks

No response

Additional context

No response

[1Naim]

CachyOS/linux@84aeeb1b171a^...21510b5 Queued for 7.0

[1Naim]

It's in repositories now. Can you check if it works correctly?

[fjoelnr]

The patch is partially working — significant progress, but speakers are still silent due to a missing SOF topology file. Here are the test results on Samsung Galaxy Book NP960XGL-XG1DE, CachyOS kernel 6.19.7-1-cachyos:
What the patch fixed:

The device is now correctly identified: card longname shows SAMSUNGELECTRONICSCO.LTD.-960XGL-P09ALX-NP960XGL_XG1DE (previously anonymous)
All 4 MAX98390 amps probe correctly at I2C 0x38, 0x39, 0x3c, 0x3d
A dedicated Speaker sink now appears in PipeWire (HiFi__Speaker__sink)
snd_hda_scodec_max98390 loads successfully
speaker-test runs without errors on the Speaker sink

What is still missing:
The SOF firmware still loads sof-hda-generic-2ch.tplg (confirmed via dmesg):
sof-audio-pci-intel-mtl: Topology file: intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
This topology has no SSP2 pipeline. According to the NHLT table, the speaker audio path on this device is:
CPU → SOF DSP → Intel SSP2 (EP1: VID=0x8086, DID=0xae30, SSP#2, Render) → MAX98390
Without an SSP2 pipeline in the topology, the SOF DSP never configures SSP2 → the MAX98390 amps receive no I2S clock/data → silence, even though the amps themselves are fully initialized.
There is currently no sof-mtl-max98390 topology file in sof-firmware 2025.12.2 or any Ubuntu/Fedora linux-firmware package.
What is needed to complete the fix:
A SOF topology file for Meteor Lake + HDA (ALC298) + MAX98390 via SSP2, and the machine driver configured to select it for this device (SSID 0x144d:0xc1d8). Is this topology being tracked in a separate PR in sof-project/topology?

[1Naim]

Hmmm, I don't think its needed. Many people have had success in that thread with just the patch so IDK what's wrong. Can you send a sudo cachyos-bugreport.sh

[fjoelnr]

Yes i sent you the bugreport

In parallel I've identified the specific root cause. Only one of the four MAX98390 amplifiers is registered as a proper ACPI device:

/sys/bus/i2c/devices/i2c-MAX98390:00  ← ACPI (0x38) ✓

The other three are dynamically instantiated as raw I2C devices (no ACPI name):

i2c i2c-2: new_device: Instantiated device max98390-hda at 0x39
i2c i2c-2: new_device: Instantiated device max98390-hda at 0x3c
i2c i2c-2: new_device: Instantiated device max98390-hda at 0x3d

[fjoelnr]

Additionally, serial_multi_instantiate kernel module is not loaded at all (lsmod | grep serial_multi returns empty). Without it, only the first amp (MAX98390:00 at 0x38) gets registered as a proper ACPI device via the DSDT entry. The other three (0x39, 0x3c, 0x3d) are added as raw I2C devices by the community DKMS workaround — but with names (2-0039, 2-003c, 2-003d) that comp_generic_fixup cannot match.
The patch appears to be missing the serial-multi-instantiate.c changes from PR #5616 that would register all four amplifiers under proper ACPI identifiers (MAX98390:00–MAX98390:03).

[1Naim]

You know it's frustrating talking to an LLM, right?

The patch appears to be missing the serial-multi-instantiate.c changes from PR #5616 that would register all four amplifiers under proper ACPI identifiers (MAX98390:00–MAX98390:03).

https://github.com/CachyOS/linux/blob/8ea7443f98ee0c3eb6abce1ea71d8621e4120743/drivers/platform/x86/serial-multi-instantiate.c#L403-L412

Yes i sent you the bugreport

where? I need the link.

[fjoelnr]

The bugreport is at: https://paste.cachyos.org/p/f79ffed.log
Regarding the LLM remark: I understand it can feel off-putting, and I apologize if the style was frustrating. The intent was to arrive at useful, precise diagnostics faster rather than going through many back-and-forth iterations with little progress. That said — a fair observation back: what's genuinely frustrating is spending hours tracking down why something as basic as laptop speakers doesn't work out of the box. That frustration is exactly what drives users back to Windows every day. So keeping that in focus matters, and any tool that helps move toward a fix faster seems worth using.
On the technical side: if serial-multi-instantiate.c is already present in the CachyOS tree, that's good to know — thank you. In that case the module should exist, but on this system lsmod | grep serial_multi returns empty and only i2c-MAX98390:00 (0x38) appears in /sys/bus/i2c/devices/ with a proper ACPI name. The other three are still instantiated as raw I2C devices.
Could it be that the SMI table entry for this device's SSID (0x144d:0xc1d8) is missing or not triggering? Or is there a module load ordering issue? Happy to test any specific command or patch.

[1Naim]

Can I have the output of

lspci -knn | paste-cachyos

[fjoelnr]

https://paste.cachyos.org/p/b784733

[1Naim]

the test results on Samsung Galaxy Book NP960XGL-XG1DE, CachyOS kernel 6.19.7-1-cachyos

Oh... I should've realized this sooner. You're not using the correct kernel. The patchset is only applied for linux-cachyos-rc. Please try that kernel.