On 08/07/2013 11:36 AM, Mark Brown wrote:
On Wed, Aug 07, 2013 at 10:26:35AM +0200, Lars-Peter Clausen wrote:
That isn't really supported right now. If muting and unmuting the control is such a complex sequence maybe it is better to stay with you previous solution, without autodisable.
Adding an event callback shouldn't be hard?
But tricky. The widget of course can have a event callback, but since the widget is created by the DAPM layer and not the codec driver there is currently no way to setup the callback. And then there is of course the question when do you want to run the callback, only if DAPM unmutes the control, if the user unmutes the control or both.
One thing that could work is to setup SND_SOC_DAPM_{PRE,POST}_REG events for the SWITCH widget. This callback gets called whenever user changes the control (and it is not disabled by DAPM). The next step then would be to set up an internal event callback for kcontrol widgets which then again calls the event callbacks for the kcontrol's widgets like we do in dapm_widget_update(). But I'm not convinced that this is the best way to solve this. I think it makes things more complicated than they need to be. I think having a OUTDRV widget along the path that runs the mute and unmute sequence might be a better option. And then have virtual switch control to let userspace disconnect the path, so that it is still possbile to manually mute it.
- Lars