Re: [PATCH v2] ALSA: hda/realtek: Enable PC beep passthrough for HP EliteBook 855 G7

["Maciej S. Szmigiero" <mail@xxxxxxxxxxxxxxxxxxxxx>]

On 17.02.2025 11:02, Takashi Iwai wrote:
> On Sun, 16 Feb 2025 22:31:03 +0100,
> Maciej S. Szmigiero wrote:
> > PC speaker works well on this platform in BIOS and in Linux until sound
> > card drivers are loaded. Then it stops working.
> >
> > There seems to be a beep generator node at 0x1a in this CODEC
> > (ALC269_TYPE_ALC215) but it seems to be only connected to capture mixers
> > at nodes 0x22 and 0x23.
> > If I unmute the mixer input for 0x1a at node 0x23 and start recording
> > from its "ALC285 Analog" capture device I can clearly hear beeps in that
> > recording.
> >
> > So the beep generator is indeed working properly, however I wasn't able to
> > figure out any way to connect it to speakers.
> >
> > However, the bits in the "Passthrough Control" register (0x36) seems to
> > work at least partially: by zeroing "B" and "h" and setting "S" I can at
> > least make the PIT PC speaker output appear either in this laptop speakers
> > or headphones (depending on whether they are connected or not).
> >
> >
> > There are some caveats, however:
> > * If the CODEC gets runtime-suspended the beeps stop so it needs HDA beep
> > device for keeping it awake during beeping.
> >
> > * If the beep generator node is generating any beep the PC beep passthrough
> > seems to be temporarily inhibited, so the HDA beep device has to be
> > prevented from using the actual beep generator node - but the beep device
> > is still necessary due to the previous point.
> >
> > * In contrast with other platforms here beep amplification has to be
> > disabled otherwise the beeps output are WAY louder than they were on pure
> > BIOS setup.
> >
> >
> > Unless someone (from Realtek probably) knows how to make the beep generator
> > node output appear in speakers / headphones using PC beep passthrough seems
> > to be the only way to make PC speaker beeping actually work on this
> > platform.
> >
> > Signed-off-by: Maciej S. Szmigiero <mail@xxxxxxxxxxxxxxxxxxxxx>
> > ---
> >
> > Since more than 6 weeks has now passed since the previous version of this
> > patch was posted, yet no better or other solution was provided I'm
> > re-submitting an updated version of the original patch.
> >      
> > This solution has been working fine for me on this platform all that time,
> > without any obvious issues.
> >      
> > Changes from v1:
> > * Correct the typo in !IS_ENABLED(CONFIG_INPUT_PCSPKR) code that the
> > kernel test robot found.
> >      
> > * Change codec_warn() into dev_warn_once(hda_codec_dev(codec))
> > to avoid spamming the kernel log at runtime PM CODEC re-init.
>
> This is really a thing to be checked by Realtek people at first, as
> it's very vendor-specific thing.
>
> Kailang, please check this.

Realtek people has been asked to comment/provide alternative solution
3 times in last 6 weeks:
On the original v1 submission, by your message from Jan 12, by my
message on Feb 2.

Looking at https://lore.kernel.org/linux-sound/?q=f%3Arealtek
it seems Kailang sent two e-mails about unrelated cases to linux-sound
during that time.

To be honest, I don't understand why Realtek people don't comment
on this since I would think that's a rather simple matter without any
truly confidential aspects but on the other hand this fact should *not*
permanently block fixing PC beep on this platform.

So I think there should be some deadline here for the vendor response -
like 1 month more or so?

> And, except for that, I'm still concerned by the behavior change.

AFAIK most sound card drivers in ALSA were developed without any docs,
and the register that's being changed is unofficially documented in ALSA:
https://docs.kernel.org/sound/hd-audio/realtek-pc-beep.html

Also, the behavior change is clearly limited to this single laptop
platform (HP EliteBook 855 G7) so the "blast radius" is very limited.

> Also the caveat you mentioned about the runtime PM raises some doubt,
> too.

I think it's simply because the CODEC get re-initialized when it comes
out of runtime PM sleep so if we print a message there then it would
be printed each time the CODEC resumed from runtime PM sleep.

That's why I changed to print this hint about CONFIG_INPUT_PCSPKR
just once per CODEC device.

> thanks,
>
> Takashi

Thanks,
Maciej