[pulseaudio-discuss] [PATCH 1/3] bluetooth: Do not switch to profile unless Playing

[Tanu Kaskinen]

On Tue, 2011-12-06 at 19:20 +0100, Dalleau, Frederic wrote:
> Hi Tanu,
> 
> > So, does this sound like correct behavior:
> >
> > module-bluetooth-discover loads module-bluetooth-device whenever
> > anything is CONNECTED. module-bluetooth-discover never sets any
> > particular profile explicitly.
> 
> module-bluetooth-discover already knows what profiles are connected
> and can hint module-bluetooth-device into what profile to use
> thus saving some ipc at loading.

If module-bluetooth-discovery already knows that, I don't see why there
needs to be any extra ipc. The device information could be shared
between module-bluetooth-discovery and module-bluetooth-device.[1]

That said, I don't think it's necessarily a very good idea to put the
profile selection logic into module-bluetooth-device after all. Neither
am I convinced that module-bluetooth-discover is the right place.

> > If the "profile" module argument is not set, module-bluetooth-device
> > activates a profile that is PLAYING at the time when the module is
> > loaded.
> see above
> 
> However I agree that splitting profile decision over two modules is
> not easy to deal with. I'd suggest that module-bluetooth-discover be
> made responsible for loading/unloading and updating profiles for the
> various instances of module-bluetooth-device.

What do you mean by "loading/unloading and updating profiles"? The
profile list is static (at least currently), so your wording sounds
strange. Do you mean the task of deciding which profile should be active
at any given time?

> module-bluetooth-device itself should only apply what is said to it.
> module-bluetooth-discover then could be able to manage profiles on
> several devices at a time for example if two headset are paired, switch
> the first to off and the second one to HSP for example.

I think it's probably the right choice to make module-bluetooth-device
stupid and only act when told so. In absence of external control,
module-bluetooth-device should default to the "off" profile.

I doesn't sound like a good idea to make module-bluetooth-discover any
smarter either. It should just load module-bluetooth-device when any
profile is at least in the "connected" state, without specifying any
profile. That's because choosing the profiles is a territory for policy
modules. If there's a central policy daemon, it will probably want to
have full control over the profiles, so module-bluetooth-device
shouldn't pretend to know what's best for the user.

Desktops probably won't have any centralized policy daemon, at least in
the near future, so some sane default policy for handling the bluetooth
profiles is needed. Since module-device-restore doesn't seem to
implement very useful policy in case of bluetooth, I think there should
be a separate policy module just for handling the bluetooth profiles.


[1] I've actually already started to implement a shared "daemon proxy"
that provides a simple interface for any module for interacting with
bluetoothd. Basically the daemon proxy stores the bluetoothd state in a
local cache, which can be immediately accessed by modules, without
having to touch D-Bus at all. I don't have concrete plans to adapt the
existing bluetooth modules to the daemon proxy; the proxy will initially
only be used by module-wl1273-support. If others see the proxy concept
useful, it should be easy to extend the proxy to cover more stuff.
module-wl1273-support only needs to access the list of adapters and the
org.bluez.FMRadio interface, so the initial functionality will be rather
limited.

-- 
Tanu