On Jul 17, 2013 6:44 AM, "Tanu Kaskinen" <<a href="mailto:tanu.kaskinen@intel.com">tanu.kaskinen@intel.com</a>> wrote: > > On Tue, 2013-07-16 at 13:04 -0300, João Paulo Rechi Vita wrote: > > On Tue, Jul 16, 2013 at 6:20 AM, Tanu Kaskinen > > <<a href="mailto:tanu.kaskinen@linux.intel.com">tanu.kaskinen@linux.intel.com</a>> wrote: > > > Another thing (I should have brought this up earlier, but I only > > > realized this today): not having a generic module-bluetooth-discover > > > breaks old configuration files, which I hate (FWIW, I believe Arun > > > doesn't care about breaking configuration compatibility that much, I > > > don't know David's opinion). João, would it be too much to ask from you > > > to write a stub module-bluetooth-discover, which checks the bluez > > > version at runtime and then loads module-bluez4-discover or > > > module-bluez5-discover depending on the detected version? > > > > > > > It was already agreed before that we would do it this way, and I don't > > think we should do a D-Bus roundtrip just to detect the BlueZ version. > > Right now we're compiling both modules by default and generating a > > <a href="http://default.pa">default.pa</a> that loads module-bluez4-discovery by default, so IMO it's > > already good enough to help packagers do the right thing. I'm not > > exactly sure what's the situation you want to improve not breaking > > configuration-file compatibility, but one way might make you happy is > > if we do not rename module-bluetooth-* to module-bluez4-* at this > > moment, and later when we decide to make BlueZ 5 support the default > > one we rename module-bluetooth-* to module-bluez4-* and > > module-bluez5-* to module-bluetooth-*. This will save us from breaking > > configuration files, but at the price of making the codebase a bit > > more confusing IMO, which I'm fine with as long as we have a good > > rationale for that. > > The scenario that I'm talking about is when a user has modified > <a href="http://default.pa">default.pa</a> (either in /etc/pulse/<a href="http://default.pa">default.pa</a> or copied the file to > ~/.config/pulse/<a href="http://default.pa">default.pa</a>). Package management tools may or may not > notify the user about the changes in /etc/pulse/<a href="http://default.pa">default.pa</a>, but they > will certainly not rewrite it automaticallly. So /etc/pulse/<a href="http://default.pa">default.pa</a> > may end up having the old contents. If the configuration is in the home > directory, the file will certainly not be updated. > If the package manager doesn't tell the user about a modified config file that's about to be overwritten by an update the fault is more on the package management software than on us. And if the user keeps <a href="http://default.pa">default.pa</a> under ~/.config he should know what he's doing. > I'm not sure why you're against doing a D-Bus round-trip. Is it for > performance reasons? Note that the round-trip is needed only if > PulseAudio is built with support for both BlueZ 4 and 5. Also, > distributions can, if they are concerned about the round-trip more than > about retaining configuration file compatibility, modify <a href="http://default.pa">default.pa</a> so > that it loads module-bluez*-discovery directly. > My concern is about wasting resources unnecessarily. We shouldn't provide one solution for distributions that doesn't care about the system resources and encourage the ones who care to use a workaround. Then when users come reporting problems we'll have to figure out what's their distro choice as another variable in the equation. And what if bluetoothd is not running when PulseAudio starts, and D-Bus activation is disabled? We will also have a filter_cb to monitor when it register itself on the bus? And we'll postpone endpoints and HandsfreeAudioAgent objects registration with the bus up to this point in this case? I think we're trying to create an artificial independence of BlueZ and PulseAudio versions to support bluetooth audio devices when we have half of the implementation in one daemon and the other half in the other. Supporting both BlueZ 4 and 5 in PulseAudio should be just a way to ease the upgrade path from BlueZ 4 to BlueZ 5. At some point we should disable the compilation of BlueZ 4 support by default and make BlueZ 5 support loaded by default in <a href="http://default.pa">default.pa</a>. What about the idea of keep calling one of the modules set module-bluetooth-*? It could maybe even be the BlueZ 5 modules called this way, so we avoid a later rename and reinforce the obsolescence of the BlueZ 4 support. -- João Paulo Rechi Vita <a href="http://about.me/jprvita">http://about.me/jprvita</a>