Dne 20. 04. 21 v 3:10 Shuming [θζΈι] napsal(a):
I see. In this case, the auto-route settings should differ from the mixer settings. So the mute flag should be logical _OR_ from both DAPM and the mixer settings. And because the codec is able to do the hw mute, why to prevent the export of this feature?
So I propose do do (pseudo code):
struct rt711_sdca_priv { bool fu0f_dapm_mute; bool fu0f_mixer_mute; };
/* called from both dapm event and kontrol put callback (on change) */ /* the dapm event and put callback will modify only rt711_sdca_priv fields */ static void set_f0f_mute(rt711_priv) { int mute = rt711_priv->fu0f_dapm_mute || rt711_priv-
fu0f_mixer_mute;
set_fu0f_mute_register(mute); }
With this implementation, all is consistent to the user space.
If so: When capture, if user setting is mute, it will always mute and if user setting is unmute, it will always unmute.
When stop capture, it will always mute regardless the user setting.
Shuming, what do you think?
I think the function could mute/unmute both. It could avoid that the setting always mutes if the user setting is unmute. e.g. static void set_fu0f_capture_ctl(rt711_priv) { int mute = rt711_priv->fu0f_dapm_mute || rt711_priv->fu0f_mixer_mute; if (mute) set_fu0f_mute_register(); else set_fu0f_unmute_register(); }
Yes, I passed the mute value in the pseudo code to the set_fu0f_mute_register() function as argument for the further evaluation, but I meant exactly this.
Thank you, Jaroslav