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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tanu,

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

At first, i thought some DBUS would be required at loading of
module-bluetooth-device but in fact this is not needed : bluetooth-util.c
contains some code that shares this information. See
pa_bluetooth_discovery_get(u->core)

> 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?
My english is what it is :) I meant loading and unloading
module-bluetooth-device, and updating the active profile for each card
upon particular events.

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

A few weeks ago I've read about a policy module on that list. So far I've
seen any updates. I have nothing against handling the profile switch in
a separate module as long as it is done. This offers an additional
advantage : that could also be used to automate loading of module-loopback
for HFP HF role and A2DP sink role.

> [1] I've actually already started to implement a shared "daemon proxy"

It is likely that a big part of what you need is already
available in bluetooth-util.c. You just need to add a field to struct
pa_bluetooth_discovery with the adapters, and a hook to call
when an adapter is added (see found_adapter) and you're done.

Regards,
Fr?d?ric


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux