lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d5a111cb-c242-4a91-8289-5441495c3ff5@maciej.szmigiero.name>
Date: Sun, 12 Jan 2025 20:23:32 +0100
From: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To: Takashi Iwai <tiwai@...e.de>, Kailang Yang <kailang@...ltek.com>
Cc: Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
 Oder Chiou <oder_chiou@...ltek.com>, Shuming Fan <shumingf@...ltek.com>,
 Qiu Wenbo <qiuwenbo@...inos.com.cn>, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: hda/realtek: Enable PC beep passthrough for HP
 EliteBook 855 G7

On 12.01.2025 13:11, Takashi Iwai wrote:
> On Wed, 01 Jan 2025 14:16:05 +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@...iej.szmigiero.name>
> 
> It's a change that does handle things completely differently from the
> current implementation, and it uses undocumented Realtek-specific
> things, so I'd rather want comments from Realtek.
> 
> Kailang, is this feature correct and can be used safely?
> 

...and if it is incorrect then it would be nice to know how to do it
the correct way.

By the way, the patch will need a respin anyway to correct the typo in
!IS_ENABLED(CONFIG_INPUT_PCSPKR) code that the kernel test robot found
and to change that codec_warn() into dev_warn_once(hda_codec_dev(codec))
to avoid spamming the kernel log at runtime PM CODEC re-init.

> thanks,
> 
> Takashi

Thanks,
Maciej


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ