On Mon, 2012-11-26 at 15:06 +0100, Mikel Astiz wrote: > Hi Tanu, > > On Mon, Nov 26, 2012 at 2:52 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > > module-bluetooth-policy has all information it needs available from > > bluetooth-util, doesn't it? It doesn't necessarily need to even care > > about the port availability, it could just directly follow the profile > > state (connected/playing). > > Actually this kind of information is missing in the bluetooth-util > library. Have a look at how module-bluetooth-device is directly > handling the property changes in filter_cb(). This can be improved of > course (patches coming soon) but I doubt it's worth addressing this > minor detail for 3.0. Fair enough. > > Am I right that the profile switching logic isn't meant for headsets > > anyway? The use case for which the code was written was enabling > > hfgw/a2dp_source when those profiles entered the "playing" state without > > pulseaudio initiating that state change, or do I remember wrong? Maybe > > module-bluetooth-policy could just check that is the port that became > > available hfgw or a2dp_source, that way there would be no risk of > > messing up headset use cases. > > Yes, that could be a possible workaround. Afaik headsets would rarely > resume the audio for a specific profile, at least in desktop > use-cases. > > As you say, we could disable the policy based on the profile to avoid > messing up with headsets, but doesn't this raise the question whether > module-bluetooth-policy should be loaded at all? I don't think the > average user will be doing both gateway and headset roles. I think playing music from a phone via bluetooth to a PC is common enough use case to justify loading module-bluetooth-policy by default. -- Tanu
