On Wed, 2013-07-17 at 23:34 -0300, Jo?o Paulo Rechi Vita wrote: > On Jul 17, 2013 6:44 AM, "Tanu Kaskinen" <tanu.kaskinen at intel.com> 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 > > > <tanu.kaskinen at linux.intel.com> 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 > > > default.pa 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 > > default.pa (either in /etc/pulse/default.pa or copied the file to > > ~/.config/pulse/default.pa). Package management tools may or may not > > notify the user about the changes in /etc/pulse/default.pa, but they > > will certainly not rewrite it automaticallly. So /etc/pulse/default.pa > > 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 > default.paunder ~/.config he should know what he's doing. If by "know what he's doing" you mean "know and accept that the configuration may break at any PulseAudio update", I disagree. We don't discourage users from copying the configuration under ~/.config. > > 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 default.pa 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. What is there to figure out? The logs and pactl list output will tell you what version is running. As for "wasting resources", the waste seems trivial to me. module-bluetooth-discover should unload itself once it has loaded module-bluez*-discover. And in case you forgot: the version auto-detection is only used if both versions are enabled in the build. > 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? Yes, if bluetoothd isn't running, then the stub module waits for it to appear. > 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 default.pa. We have to support both BlueZ 4 and BlueZ 5, there's nothing artificial about that. BlueZ 4 getting disabled by default will take care of itself automatically eventually, because nobody is going to have the pre-requisite bluez 4 pkg-config file installed when building pulseaudio. > 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. If you build support for both versions, we can't know which version will be used at runtime, so the default configuration will only work half the time. -- Tanu
