On Sat, 02 Nov 2024 00:15:24 +0100,
Jarosław Janik wrote:
>
> On 11/1/24 09:18, Takashi Iwai wrote:
>
> >> Well, to what I recall - my (current) Thinkpad has never beeped on
> >> shutdown, other than that - without your "extra muting" patch - yes -
> >> beeping in every other circumstances works no matter if HDA controller
> >> is in PM suspend or not; this is what I've got used to for many years of
> >> using Thinkpads.
> >
> > Do you mean about the beep emitted via thinkpad_acpi stuff or the
> > normal beep via terminal etc? The latter must work even with the
> > patch, but the question is only about the former. And that's the case
> > for the shutdown beep tone.
>
> Yes, I meant beeps emitted by ACPI firmware and I'm not confusing them
> with beeps generated by linux console - as you said - the latter work
> fine no matter if your patch is applied or not, the former only work
> fine if that patch is reverted.
OK.
> BTW. The ACPI beeps we are talking about are not emitted by
> thinkapd_acpi module, but by ACPI firmware; you can take a look at how
> thinpad_acpi handles writes to /proc/acpi/ibm/beep - it doesn't make any
> beep itself, it just injects some "fake" ACPI event - and beep is
> generated by laptop's firmware in response to that event (the
> terminology here might not be too good, because my knowledge of ACPI is
> rather modest).
>
> Anyway - with that being said - when it comes to the lack of beep on
> shutdown on *my* laptop - this must be because of *my* laptop's APCI
> firmware just doesn't emit beep for this specific event.
Yes, it seems like that.
> > You can pass snd_hda_intel.beep_mode=0 option to disable HD-audio
> > beep, verify the device being runtime-suspended, and check whether the
> > beep via thinkpad_acpi still works (after reverting).
>
> Yes, that works.
> I've even had another test - with patch applied I increased power_save
> param in this module to 3 seconds and now:
> - when I unplug AC - there is no beep, because device is PM suspended
> - now I hit Tab in bash on linux console, kernel emits beep and keeps
> device awaken for 3 more seconds - so I quickly unplug AC - there is a
> beep, then wait ~3 seconds and plug it back - no beep now. That shall
> prove that our understanding of what's going on is OK.
For checking the runtime-suspend, at best check the sysfs file entry.
e.g. cat /sys/bus/hdaudio/devices/hdaudioC0D0/power/runtime_status
And, I see that Conexant codec doesn't have the beep generator but
it's only passthrough. Then beep_mode option doesn't change
anything, but the "Beep" mixer volume/switch may influence on the
behavior; not only the beep volume but also the runtime-suspend
behavior. You can try adjusting the volume/switch if it influences on
anything.
In anyway, you can try unload pcspkr module as well. This is the
Linux input device for the beep in your case. (For Realtek codecs,
there can be additional beep input device driven by HD-audio codec
itself, and that's managed via beep_mode module option).
Without pcspkr, the beep from the terminal shouldn't work -- unless
it's handled by the sound server like pulesaudio. And, if I
understand correctly from your description, even without pcspkr, the
firmware beep should keep working.
As you see, the simple beeping stuff is really complex due to its
history. Although it's a legacy feature, a few people still love it,
hence it can't go away soon :)
Takashi
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]