[alsa-devel] [bug?, 3.1 -> 3.2.7 regression] ALC269 (ThinkPad L412): auto-mute mode disabled by default
Hi Takashi et al,
Pavel Yakunin wrote[1]:
There is a problem with a headphones jack detection in the 3.2 kernel for the ALC269 codec: sound comes from both speaker and headphones simultaneously and never switches between them.
The problem arised when I upgraded my system to the 3.2 kernel, and when I rolled back to the 3.1 kernel, everything was ok.
It turned out to be due to the auto-mute mode control, which is present on this model in 3.2 and not 3.1, being disabled by default.
On 2012-03-05 05:16, Jonathan Nieder wrote:
One more test: if you run "alsactl init" as root, does the auto-mute mode control end up enabled or disabled?
[...]
It ends up disabled.
Versions tested:
3.1.y - auto-mute works, no auto-mute control present 3.2.y - auto-mute disabled by default but control works sound/for-next as of 2012-03-03 - likewise
Is this behavior intended?
More details, including alsa-info.sh logs, at [1].
Thanks, Jonathan
At Mon, 5 Mar 2012 13:40:30 -0600, Jonathan Nieder wrote:
Hi Takashi et al,
Pavel Yakunin wrote[1]:
There is a problem with a headphones jack detection in the 3.2 kernel for the ALC269 codec: sound comes from both speaker and headphones simultaneously and never switches between them.
The problem arised when I upgraded my system to the 3.2 kernel, and when I rolled back to the 3.1 kernel, everything was ok.
It turned out to be due to the auto-mute mode control, which is present on this model in 3.2 and not 3.1, being disabled by default.
On 2012-03-05 05:16, Jonathan Nieder wrote:
One more test: if you run "alsactl init" as root, does the auto-mute mode control end up enabled or disabled?
[...]
It ends up disabled.
Versions tested:
3.1.y - auto-mute works, no auto-mute control present 3.2.y - auto-mute disabled by default but control works sound/for-next as of 2012-03-03 - likewise
Is this behavior intended?
More details, including alsa-info.sh logs, at [1].
The auto-mute mode is enabled as default. It hasn't been changed at all.
So, it must have been disabled manually in the user-space side, likely accidentally. The saved asound.state is also evaluated by "alsactl init", thus unless you clean it up, the disabled auto-mute status is still applied.
Takashi
Thanks, Jonathan
Takashi Iwai wrote:
Jonathan Nieder wrote:
More details, including alsa-info.sh logs, at [1].
The auto-mute mode is enabled as default. It hasn't been changed at all.
So, it must have been disabled manually in the user-space side, likely accidentally. The saved asound.state is also evaluated by "alsactl init", thus unless you clean it up, the disabled auto-mute status is still applied.
Thanks, this must be what I missed.
What is the difference between "alsactl init" and "alsactl restore", then?
Puzzled, Jonathan
At Mon, 5 Mar 2012 13:53:15 -0600, Jonathan Nieder wrote:
Takashi Iwai wrote:
Jonathan Nieder wrote:
More details, including alsa-info.sh logs, at [1].
The auto-mute mode is enabled as default. It hasn't been changed at all.
So, it must have been disabled manually in the user-space side, likely accidentally. The saved asound.state is also evaluated by "alsactl init", thus unless you clean it up, the disabled auto-mute status is still applied.
Thanks, this must be what I missed.
Argh, sorry, I mixed something up.
Indeed, "alsactl init" doesn't restore the state.
But, "alsactl init" also doesn't reset the controls it doesn't care. Thus even if you re-run "alsactl init", the auto-mute state won't be changed.
Takashi
participants (2)
-
Jonathan Nieder -
Takashi Iwai