From: "Theo de Raadt" Subject: Re: audio(4): postpone volume changes to the end of DVACT_WAKEUP To: Alexandre Ratchov Cc: Mark Kettenis , tech@openbsd.org Date: Tue, 13 Aug 2024 21:01:00 -0600 Alexandre Ratchov 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 > > > > > > 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.