Re: [PATCH 0/2] Fix beep notifications by Thinkpad's ACPI firmware

[Takashi Iwai <tiwai@suse.de>]

On Wed, 30 Oct 2024 18:18:11 +0100,
Jarosław Janik wrote:
> 
> In Comment 17 of the following bug report:
> https://bugzilla.suse.com/show_bug.cgi?id=1228269
> user tigerlily had complained about "audible blip on shutdown" on a
> Thinkpad laptop, that led to a commit 4f61c8fe3520 ("ALSA: hda/conexant:
> Mute speakers at suspend / shutdown"), which mutes speakers on system
> shutdown or whenever HDA controller is suspended by PM. The
> aforementioned "blip" is a feature, not a bug however - Thinkpad's ACPI
> firmware uses short beeps / beep sequences as notifications in response
> to various events (enter/leave suspend or hibernation, AC power
> connect/disconnect, low battery, etc.); these can also be triggered by
> writing to /proc/acpi/ibm/beep, see details here:
> https://www.kernel.org/doc/html/v5.4/admin-guide/laptops/thinkpad-acpi.html#acpi-sounds-proc-acpi-ibm-beep
> The firmware doesn't touch any mixer, so depending on current mixer
> settings these beeps can be loud, silent or even muted completely,
> whatever has been set by the user.
> 
> The patch in question interferes this badly:
> - suspend/hibernate/shutdown related events are muted altogether because
>   HDA controller is in suspend mode when they occur (or snd_hda_intel
>   module has been closed in the event of system shutdown)
> - other events work "randomly", e.g. you can hear AC plug/unplug beep
>   if something is playing audio at the moment, otherwise the HDA
>   controller is likely in suspend mode, so you can't hear anything
>   (unless you disabled PM in snd_hda_intel module).
> 
> That said - let's revert this; this is what 1st commit does, the 2nd
> commit is somewhat optional - it removes helpers introduced to implement
> this muting, as they are no longer used.

As it's a regression, it's OK for the first revert, but the function
is useful for other purposes and other devices, so I'd like to keep
it.  I'm going to apply only the first patch.

> PS. Don't forget to have this backported to LTS kernels, please.

This should be taken usually automatically as long as Fixes tag points
to the right commit.

Per reading the patch description, though, the behavior appears to be
pretty unreliable, as it depends on the runtime suspend.  We may
control the runtime PM better if we know that the beep must be
submitted; or it's even possible to runtime resume/re-suspend upon
beeping, too.  But it's maybe too complex than needed.


thanks,

Takashi