[pulseaudio-discuss] [PATCH 00/56] Refactor of BlueZ 5 support

[João Paulo Rechi Vita]

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.

> 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.

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 default.pa.

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
http://about.me/jprvita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20130717/a5584873/attachment.html>