Hi Tanu,<br><br><div class="gmail_quote">On Mon, Jan 16, 2012 at 8:22 PM, Tanu Kaskinen <span dir="ltr">&lt;<a href="mailto:tanuk@iki.fi" target="_blank">tanuk@iki.fi</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div><br>
</div>Do you think it would be a lot of work to move this logic to a separate<br>
module? As discussed before[1], I&#39;d prefer there to be<br>
&quot;module-bluetooth-policy&quot; that would take care of choosing profiles<br>
automatically etc. Autoloading module-loopback could be the first<br>
feature of that module.<br></blockquote><div><br>Doing a separate module has been the first thing I tried. But there are several reasons which made me try differently  :<br>* I needed finer control by being into module-bluetooth-device than hooks : when a sink is being removed it is not possible to 
remove the sink inputs that were previously affected to it because the 
sink input has started moving and this triggers an assertion. I had to unload module-loopback before the sink inputs would start moving.<br>* I wanted to avoid having loopback enabled for unwanted modules that could cause uncontrolled side effects.<br>
* IIRC Some specific other modules (USB) could benefit of similar behavior.<br>* The code isn&#39;t too big.<br>
<br> Maybe I&#39;m trying to get complicated in that I&#39;d rather explicitly remove the loopback instead of letting it die.<br><br>So that&#39;s not a big bunch of work to do a module, but I&#39;m open ideas to fix the issues encountered before that. It&#39;s an RFC after all ;)<br>
<br>Regards,<br>Frédéric<br></div></div><br>