Hi Tanu, On Mon, Feb 18, 2013 at 5:59 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > On Mon, 2013-02-18 at 09:10 +0100, Mikel Astiz wrote: >> From: Mikel Astiz <mikel.astiz at bmw-carit.de> >> >> Second proposal integrating Tanu's comments: >> 1. pa_availability_t used for both port and profile availability. >> 2. Carefully consider profile "off" in automatic profiles witch policies. >> 3. Availability of "bluetooth-input" and "bluetooth-output" handled separately. >> >> From original cover-letter: >> >> It has been recently discussed how ports should be used in the >> Bluetooth card module, whether they should be merged or not, and how >> the bluetooth-related information is exposed to both external >> components (i.e. UI) and internal policy modules. >> >> In a nutshell, the problem is as follows: the internal policies are >> interested in profile-specific information (HSP/HFP vs A2DP) while the >> ports should ideally be associated to physical entities (and the >> Bluetooth profile should make no difference). >> >> A natural way to solve this problem is by adding a new flag to the >> card profiles, representing the availability of each profile. This is >> similar to port-availability but with different semantics, >> representing the state of each invidivual Bluetooth profile. >> >> This patchset extends the core with such a flag, which sounds useful >> even beyond the scope of this specific problem (a UI could use this >> information to gray out profiles). >> >> Mikel Astiz (6): >> core: Rename pa_available_t to pa_available_t >> card: Add card profile availability >> cli: Show card profile availability status >> bluetooth: Expose card profile availability >> bluetooth: Use profile availability to auto-switch profiles >> bluetooth: Merge all ports into "bluetooth-input" and >> "bluetooth-output" >> >> src/modules/alsa/alsa-mixer.c | 12 +- >> src/modules/alsa/alsa-mixer.h | 2 +- >> src/modules/alsa/alsa-ucm.c | 4 +- >> src/modules/alsa/module-alsa-card.c | 10 +- >> src/modules/bluetooth/module-bluetooth-device.c | 324 +++++++----------------- >> src/modules/bluetooth/module-bluetooth-policy.c | 105 ++++---- >> src/modules/module-switch-on-port-available.c | 20 +- >> src/pulse/def.h | 18 +- >> src/pulse/introspect.c | 10 +- >> src/pulse/introspect.h | 6 +- >> src/pulsecore/card.c | 20 ++ >> src/pulsecore/card.h | 4 + >> src/pulsecore/cli-text.c | 13 +- >> src/pulsecore/core.h | 1 + >> src/pulsecore/device-port.c | 10 +- >> src/pulsecore/device-port.h | 4 +- >> src/utils/pactl.c | 4 +- >> 17 files changed, 228 insertions(+), 339 deletions(-) > > Thank you! I've applied all. Thanks again for the review. > > The port renaming causes some problems if the old names are saved > anywhere. PulseAudio saves the port names in the card-restore database > (it's used for saving the port latency offset). We don't know how many > users use the old port names for something (e.g. in scripts). > > I wonder if we should have an alias database, which would be populated > with old port names whenever a port is created. This could make sense to keep backward compatibility, but I think it's overkill. > > Another question is that should the port names reflect the device form > factor? IIRC, David has previously argued that they should. I'm not so > sure. If we don't have the port alias database, there would some > breakage whenever we learn a new form factor (not a common occurrence, > but still). I already have some patches that follow David's proposal, which I will probably submit today. AFAIK the form factor of a paired device should remain constant so I can't think of a real-life issue with port names. There's no real use-case for this. In the worst case, if a device hypothetically changes the form factor due to some strange reason, it's not clear whether the old port settings/policies should apply. So I wouldn't bother much about this. Cheers, Mikel
