Index | Thread | Search

From:
"Theo de Raadt" <deraadt@openbsd.org>
Subject:
Re: audio(4): postpone volume changes to the end of DVACT_WAKEUP
To:
Alexandre Ratchov <alex@caoua.org>
Cc:
Mark Kettenis <mark.kettenis@xs4all.nl>, tech@openbsd.org
Date:
Tue, 13 Aug 2024 21:01:00 -0600

Download raw body.

Thread
Alexandre Ratchov <alex@caoua.org> wrote:

> On Wed, Aug 14, 2024 at 12:17:27AM +0200, Mark Kettenis wrote:
> > > Date: Tue, 13 Aug 2024 15:11:26 +0200
> > > From: Alexandre Ratchov <alex@caoua.org>
> > > 
> > > During DVACT_WAKEUP, acpithinkpad(4) restores the speaker mute control
> > > using the wskbd interface with a value obtained from the acpi
> > > controller. As the audio(4) driver saves and restores the full mixer
> > > state, the mute control is overwritten with the value saved during
> > > suspend, which is not acpithinkpad(4)'s intent.
> > > 
> > > As both saved and acpithinkpad states are the same most (all?) of the
> > > time the problems stays unnoticed, but let's fix it.
> > > 
> > > So, postpone changes with the wskbd interface until the end of the
> > > mixer's DVACT_WAKEUP section of audio(4).
> > 
> > That is a good idea.  Not sure how you spotted this, but I was playing
> > around with having azalia(4) do its suspend/resume in
> > DVACT_QUIESCE/DVACT_WAKEUP and this fixes the
> > 
> 
> Same here, moved all the suspend/reaume logic to
> DVACT_{QUIESCE,WAKEUP} which just worked for S3 suspend, btw.

I disagree strongly with that idea.  It may work in one driver, but it
won't work in all of them.

But then someone will write or modify another driver, and look at the
wrong example, and muddle it all up.

Please keep this seperate.  There are actions best done while cold.