[PATCH] ALSA: hda/realtek: Enable speakers on further Samsung Galaxy Book2 Pro

[PATCH] ALSA: hda/realtek: Enable speakers on further Samsung Galaxy Book2 Pro

[Benjamin Berg]

There is a further NP950QED variant of the Samsung Galaxy Book2 Pro
which has two speakers. Use the appropriate two speaker quirk for it.

Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>

---

Note that I didn't really manage to test this directly. Trying to do a
reconfigure resulted in a hang and I didn't figure out how to use the
patch= option with a firmware file.
However, the machine does work fine when configuring the two speakers
from userspace, so I am confident that this patch is correct.
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index c735f630ecb5..e4ea5ea5bb27 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -10758,6 +10758,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x144d, 0xca06, "Samsung Galaxy Book3 360 (NP730QFG)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
 	SND_PCI_QUIRK(0x144d, 0xc868, "Samsung Galaxy Book2 Pro (NP930XED)", ALC298_FIXUP_SAMSUNG_AMP),
 	SND_PCI_QUIRK(0x144d, 0xc870, "Samsung Galaxy Book2 Pro (NP950XED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
+	SND_PCI_QUIRK(0x144d, 0xc01d, "Samsung Galaxy Book2 Pro (NP950QED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
 	SND_PCI_QUIRK(0x144d, 0xc872, "Samsung Galaxy Book2 Pro (NP950XEE)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
 	SND_PCI_QUIRK(0x144d, 0xc886, "Samsung Galaxy Book3 Pro (NP964XFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
 	SND_PCI_QUIRK(0x144d, 0xc1ca, "Samsung Galaxy Book3 Pro 360 (NP960QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
-- 
2.49.0

Re: [PATCH] ALSA: hda/realtek: Enable speakers on further Samsung Galaxy Book2 Pro

[Takashi Iwai]

On Wed, 26 Mar 2025 21:19:53 +0100,
Benjamin Berg wrote:
> Note that I didn't really manage to test this directly. Trying to do a
> reconfigure resulted in a hang and I didn't figure out how to use the
> patch= option with a firmware file.
> However, the machine does work fine when configuring the two speakers
> from userspace, so I am confident that this patch is correct.

FYI, the equivalent can be achieved with model option, too.
e.g. passing model=144d:c870 will apply the same existing quirk as
SSID 144d:c870.  If your target is the secondary codec, pass like
"model=,144d:c870" instead.

> ---
>  sound/pci/hda/patch_realtek.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index c735f630ecb5..e4ea5ea5bb27 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -10758,6 +10758,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
>  	SND_PCI_QUIRK(0x144d, 0xca06, "Samsung Galaxy Book3 360 (NP730QFG)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
>  	SND_PCI_QUIRK(0x144d, 0xc868, "Samsung Galaxy Book2 Pro (NP930XED)", ALC298_FIXUP_SAMSUNG_AMP),
>  	SND_PCI_QUIRK(0x144d, 0xc870, "Samsung Galaxy Book2 Pro (NP950XED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> +	SND_PCI_QUIRK(0x144d, 0xc01d, "Samsung Galaxy Book2 Pro (NP950QED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
>  	SND_PCI_QUIRK(0x144d, 0xc872, "Samsung Galaxy Book2 Pro (NP950XEE)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
>  	SND_PCI_QUIRK(0x144d, 0xc886, "Samsung Galaxy Book3 Pro (NP964XFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
>  	SND_PCI_QUIRK(0x144d, 0xc1ca, "Samsung Galaxy Book3 Pro 360 (NP960QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),

The table is sorted in PCI SSID order.  Could you try to put at the
right position?


thanks,

Takashi

Re: [PATCH] ALSA: hda/realtek: Enable speakers on further Samsung Galaxy Book2 Pro

[Benjamin Berg]

On Thu, 2025-03-27 at 10:05 +0100, Takashi Iwai wrote:
> On Wed, 26 Mar 2025 21:19:53 +0100,
> Benjamin Berg wrote:
> > Note that I didn't really manage to test this directly. Trying to
> > do a
> > reconfigure resulted in a hang and I didn't figure out how to use
> > the
> > patch= option with a firmware file.
> > However, the machine does work fine when configuring the two
> > speakers
> > from userspace, so I am confident that this patch is correct.
> 
> FYI, the equivalent can be achieved with model option, too.
> e.g. passing model=144d:c870 will apply the same existing quirk as
> SSID 144d:c870.  If your target is the secondary codec, pass like
> "model=,144d:c870" instead.

Hmm, it is probably really straight forward, but I didn't grasp the
documentation in Documentation/sound/hd-audio/notes.rst on a quick
read. I am not sure anymore what I did (and I don't have access to the
machine anymore). It might be I tried putting the model= line into a
firmware file instead of just passing it on the kernel command line.

How do I even know whether it is the first or second codec? Is that
what the D0 in hwC0D0 is?

> 
> > ---
> >  sound/pci/hda/patch_realtek.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index c735f630ecb5..e4ea5ea5bb27 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -10758,6 +10758,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
> >  	SND_PCI_QUIRK(0x144d, 0xca06, "Samsung Galaxy Book3 360 (NP730QFG)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
> >  	SND_PCI_QUIRK(0x144d, 0xc868, "Samsung Galaxy Book2 Pro (NP930XED)", ALC298_FIXUP_SAMSUNG_AMP),
> >  	SND_PCI_QUIRK(0x144d, 0xc870, "Samsung Galaxy Book2 Pro (NP950XED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> > +	SND_PCI_QUIRK(0x144d, 0xc01d, "Samsung Galaxy Book2 Pro (NP950QED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> >  	SND_PCI_QUIRK(0x144d, 0xc872, "Samsung Galaxy Book2 Pro (NP950XEE)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> >  	SND_PCI_QUIRK(0x144d, 0xc886, "Samsung Galaxy Book3 Pro (NP964XFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
> >  	SND_PCI_QUIRK(0x144d, 0xc1ca, "Samsung Galaxy Book3 Pro 360 (NP960QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
> 
> The table is sorted in PCI SSID order.  Could you try to put at the
> right position?

Sorry, will fix and resend.

Benjamin

Re: [PATCH] ALSA: hda/realtek: Enable speakers on further Samsung Galaxy Book2 Pro

[Takashi Iwai]

On Thu, 27 Mar 2025 10:55:04 +0100,
Benjamin Berg wrote:
> 
> On Thu, 2025-03-27 at 10:05 +0100, Takashi Iwai wrote:
> > On Wed, 26 Mar 2025 21:19:53 +0100,
> > Benjamin Berg wrote:
> > > Note that I didn't really manage to test this directly. Trying to
> > > do a
> > > reconfigure resulted in a hang and I didn't figure out how to use
> > > the
> > > patch= option with a firmware file.
> > > However, the machine does work fine when configuring the two
> > > speakers
> > > from userspace, so I am confident that this patch is correct.
> > 
> > FYI, the equivalent can be achieved with model option, too.
> > e.g. passing model=144d:c870 will apply the same existing quirk as
> > SSID 144d:c870.  If your target is the secondary codec, pass like
> > "model=,144d:c870" instead.
> 
> Hmm, it is probably really straight forward, but I didn't grasp the
> documentation in Documentation/sound/hd-audio/notes.rst on a quick
> read.

It's mentioned in "Model Option" subsection of that document.
```
A new style for the model option that was introduced since 5.15 kernel
is to pass the PCI or codec SSID in the form of ``model=XXXX:YYYY``
where XXXX and YYYY are the sub-vendor and sub-device IDs in hex
numbers, respectively.  This is a kind of aliasing to another device;
when this form is given, the driver will refer to that SSID as a
reference to the quirk table.  It'd be useful especially when the
target quirk isn't listed in the model table.  For example, passing
model=103c:8862 will apply the quirk for HP ProBook 445 G8 (which
isn't found in the model table as of writing) as long as the device is
handled equivalently by the same driver.
```

> I am not sure anymore what I did (and I don't have access to the
> machine anymore). It might be I tried putting the model= line into a
> firmware file instead of just passing it on the kernel command line.

> How do I even know whether it is the first or second codec? Is that
> what the D0 in hwC0D0 is?

I meant the device probe order, so card#0 device#0 must be the very
first one :)


> > > ---
> > >  sound/pci/hda/patch_realtek.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > > index c735f630ecb5..e4ea5ea5bb27 100644
> > > --- a/sound/pci/hda/patch_realtek.c
> > > +++ b/sound/pci/hda/patch_realtek.c
> > > @@ -10758,6 +10758,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
> > >  	SND_PCI_QUIRK(0x144d, 0xca06, "Samsung Galaxy Book3 360 (NP730QFG)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
> > >  	SND_PCI_QUIRK(0x144d, 0xc868, "Samsung Galaxy Book2 Pro (NP930XED)", ALC298_FIXUP_SAMSUNG_AMP),
> > >  	SND_PCI_QUIRK(0x144d, 0xc870, "Samsung Galaxy Book2 Pro (NP950XED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> > > +	SND_PCI_QUIRK(0x144d, 0xc01d, "Samsung Galaxy Book2 Pro (NP950QED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> > >  	SND_PCI_QUIRK(0x144d, 0xc872, "Samsung Galaxy Book2 Pro (NP950XEE)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> > >  	SND_PCI_QUIRK(0x144d, 0xc886, "Samsung Galaxy Book3 Pro (NP964XFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
> > >  	SND_PCI_QUIRK(0x144d, 0xc1ca, "Samsung Galaxy Book3 Pro 360 (NP960QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
> > 
> > The table is sorted in PCI SSID order.  Could you try to put at the
> > right position?
> 
> Sorry, will fix and resend.

Thanks!


Takashi

Re: [PATCH] ALSA: hda/realtek: Enable speakers on further Samsung Galaxy Book2 Pro

[Benjamin Berg]

On Thu, 2025-03-27 at 11:09 +0100, Takashi Iwai wrote:
> On Thu, 27 Mar 2025 10:55:04 +0100,
> Benjamin Berg wrote:
> > 
> > On Thu, 2025-03-27 at 10:05 +0100, Takashi Iwai wrote:
> > > On Wed, 26 Mar 2025 21:19:53 +0100,
> > > Benjamin Berg wrote:
> > > > Note that I didn't really manage to test this directly. Trying to
> > > > do a
> > > > reconfigure resulted in a hang and I didn't figure out how to use
> > > > the
> > > > patch= option with a firmware file.
> > > > However, the machine does work fine when configuring the two
> > > > speakers
> > > > from userspace, so I am confident that this patch is correct.
> > > 
> > > FYI, the equivalent can be achieved with model option, too.
> > > e.g. passing model=144d:c870 will apply the same existing quirk as
> > > SSID 144d:c870.  If your target is the secondary codec, pass like
> > > "model=,144d:c870" instead.
> > 
> > Hmm, it is probably really straight forward, but I didn't grasp the
> > documentation in Documentation/sound/hd-audio/notes.rst on a quick
> > read.
> 
> It's mentioned in "Model Option" subsection of that document.
> ```
> A new style for the model option that was introduced since 5.15 kernel
> is to pass the PCI or codec SSID in the form of ``model=XXXX:YYYY``
> where XXXX and YYYY are the sub-vendor and sub-device IDs in hex
> numbers, respectively.  This is a kind of aliasing to another device;
> when this form is given, the driver will refer to that SSID as a
> reference to the quirk table.  It'd be useful especially when the
> target quirk isn't listed in the model table.  For example, passing
> model=103c:8862 will apply the quirk for HP ProBook 445 G8 (which
> isn't found in the model table as of writing) as long as the device is
> handled equivalently by the same driver.
> ```
> 
> > I am not sure anymore what I did (and I don't have access to the
> > machine anymore). It might be I tried putting the model= line into a
> > firmware file instead of just passing it on the kernel command line.
> 
> > How do I even know whether it is the first or second codec? Is that
> > what the D0 in hwC0D0 is?
> 
> I meant the device probe order, so card#0 device#0 must be the very
> first one :)

Right, that make sense, but wasn't obvious to me then.

Unfortunately, it seems that I messed something up and I cannot fully
put it back together now.

I have one photo of the sysfs entries, and the subsystem_id is
0x144dc1ac there. So now I am not entirely certain that this is the
correct ID, because I might have successfully overridden it to an
incorrect value.
Lkely, it is correct, but I do not know where I got the 0xc01d from.

Sorry,
Benjamin

> > > > ---
> > > >  sound/pci/hda/patch_realtek.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > > > index c735f630ecb5..e4ea5ea5bb27 100644
> > > > --- a/sound/pci/hda/patch_realtek.c
> > > > +++ b/sound/pci/hda/patch_realtek.c
> > > > @@ -10758,6 +10758,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
> > > >  	SND_PCI_QUIRK(0x144d, 0xca06, "Samsung Galaxy Book3 360 (NP730QFG)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
> > > >  	SND_PCI_QUIRK(0x144d, 0xc868, "Samsung Galaxy Book2 Pro (NP930XED)", ALC298_FIXUP_SAMSUNG_AMP),
> > > >  	SND_PCI_QUIRK(0x144d, 0xc870, "Samsung Galaxy Book2 Pro (NP950XED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> > > > +	SND_PCI_QUIRK(0x144d, 0xc01d, "Samsung Galaxy Book2 Pro (NP950QED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> > > >  	SND_PCI_QUIRK(0x144d, 0xc872, "Samsung Galaxy Book2 Pro (NP950XEE)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
> > > >  	SND_PCI_QUIRK(0x144d, 0xc886, "Samsung Galaxy Book3 Pro (NP964XFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
> > > >  	SND_PCI_QUIRK(0x144d, 0xc1ca, "Samsung Galaxy Book3 Pro 360 (NP960QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
> > > 
> > > The table is sorted in PCI SSID order.  Could you try to put at the
> > > right position?
> > 
> > Sorry, will fix and resend.
> 
> Thanks!
> 
> 
> Takashi
> 

Re: [PATCH] ALSA: hda/realtek: Enable speakers on further Samsung Galaxy Book2 Pro

[Takashi Iwai]

On Thu, 27 Mar 2025 11:26:20 +0100,
Benjamin Berg wrote:
> 
> On Thu, 2025-03-27 at 11:09 +0100, Takashi Iwai wrote:
> > On Thu, 27 Mar 2025 10:55:04 +0100,
> > Benjamin Berg wrote:
> > > 
> > > On Thu, 2025-03-27 at 10:05 +0100, Takashi Iwai wrote:
> > > > On Wed, 26 Mar 2025 21:19:53 +0100,
> > > > Benjamin Berg wrote:
> > > > > Note that I didn't really manage to test this directly. Trying to
> > > > > do a
> > > > > reconfigure resulted in a hang and I didn't figure out how to use
> > > > > the
> > > > > patch= option with a firmware file.
> > > > > However, the machine does work fine when configuring the two
> > > > > speakers
> > > > > from userspace, so I am confident that this patch is correct.
> > > > 
> > > > FYI, the equivalent can be achieved with model option, too.
> > > > e.g. passing model=144d:c870 will apply the same existing quirk as
> > > > SSID 144d:c870.  If your target is the secondary codec, pass like
> > > > "model=,144d:c870" instead.
> > > 
> > > Hmm, it is probably really straight forward, but I didn't grasp the
> > > documentation in Documentation/sound/hd-audio/notes.rst on a quick
> > > read.
> > 
> > It's mentioned in "Model Option" subsection of that document.
> > ```
> > A new style for the model option that was introduced since 5.15 kernel
> > is to pass the PCI or codec SSID in the form of ``model=XXXX:YYYY``
> > where XXXX and YYYY are the sub-vendor and sub-device IDs in hex
> > numbers, respectively.  This is a kind of aliasing to another device;
> > when this form is given, the driver will refer to that SSID as a
> > reference to the quirk table.  It'd be useful especially when the
> > target quirk isn't listed in the model table.  For example, passing
> > model=103c:8862 will apply the quirk for HP ProBook 445 G8 (which
> > isn't found in the model table as of writing) as long as the device is
> > handled equivalently by the same driver.
> > ```
> > 
> > > I am not sure anymore what I did (and I don't have access to the
> > > machine anymore). It might be I tried putting the model= line into a
> > > firmware file instead of just passing it on the kernel command line.
> > 
> > > How do I even know whether it is the first or second codec? Is that
> > > what the D0 in hwC0D0 is?
> > 
> > I meant the device probe order, so card#0 device#0 must be the very
> > first one :)
> 
> Right, that make sense, but wasn't obvious to me then.
> 
> Unfortunately, it seems that I messed something up and I cannot fully
> put it back together now.
> 
> I have one photo of the sysfs entries, and the subsystem_id is
> 0x144dc1ac there. So now I am not entirely certain that this is the
> correct ID, because I might have successfully overridden it to an
> incorrect value.
> Lkely, it is correct, but I do not know where I got the 0xc01d from.

144d:c01d can be PCI SSID while 144d:c1ac is the codec SSID.
Both are matched by the driver (PCI SSID is matched primarily).
In many cases the vendor sets different ID numbers.


Takashi