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

[Takashi Iwai <tiwai@suse.de>]

On Mon, 17 Feb 2025 11:17:31 +0100,
Maciej S. Szmigiero wrote:
> 
> 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@maciej.szmigiero.name>
> >> ---
> >> 
> >> 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?

Sorry, I don't like that kind of attitude.

If the patch were perfectly fine, I'd have already taken.  But there
is a thing that can't be validated without the confirmation from the
vendor, and that's not what we can accept because it's supposed to
work on your machine -- that's only one special use case, and it
doesn't qualify to prove the safety.

In general, Kailang (and Realtek) has been helpful over decades for
HD-audio stuff development, but they might be busy sometimes.  Let's
keep asking until catching their attention, at first.

> > 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.

If you were the only user of this laptop in the world, I wouldn't be
concerned, sure :)  But certainly that's not the case.

> > 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.

Well, but this runtime PM has to be turned off manually, otherwise the
beep gets broken, right?  This is already some trade-off, so it's not
super trivial to apply the suggested change blindly.

I thought that the input beep infrastructure may work with multiple
input beep devices, and it usually triggers the all beep devices?
If so, you can still keep the HD-audio beep (even though it doesn't do
actually output) so that it can manage the runtime PM of HD-audio
device at beeping, too.


thanks,

Takashi