[pulseaudio-discuss] [PATCH v0 07/20] Consider unknown availability in module-switch-on-port-available

[Mikel Astiz]

Hi David,

On Wed, Aug 22, 2012 at 11:13 AM, David Henningsson
<david.henningsson at canonical.com> wrote:
> On 08/22/2012 10:08 AM, Mikel Astiz wrote:
>>
>> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>>
>> A port with the availability state flag set to unknown should not be
>> considered an active port.
>> ---
>>   src/modules/module-switch-on-port-available.c |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/modules/module-switch-on-port-available.c
>> b/src/modules/module-switch-on-port-available.c
>> index 1da612d..8c16821 100644
>> --- a/src/modules/module-switch-on-port-available.c
>> +++ b/src/modules/module-switch-on-port-available.c
>> @@ -85,7 +85,7 @@ static pa_bool_t try_to_switch_profile(pa_card *card,
>> pa_device_port *port) {
>>               PA_IDXSET_FOREACH(sink, card->sinks, state2) {
>>                   if (!sink->active_port)
>>                       continue;
>> -                if (sink->active_port->available != PA_PORT_AVAILABLE_NO)
>> +                if (sink->active_port->available ==
>> PA_PORT_AVAILABLE_YES)
>>                       found_active_port = TRUE;
>>               }
>>
>>
>
> I think this will break the following use case (on a normal laptop) :
>
> Assume we plug in HDMI. With this patch we will get inconsistent behaviour:
> if headphones are plugged in (available = yes), we won't switch to HDMI, but
> if not (speakers are available = unknown), we will switch to HDMI.

After the interesting discussion in IRC, I see two options:

(a) module-switch-on-port-available is modified such that the HDMI
case is treated explicitly, given that this check is there
specifically for HDMI. It would be a policy like
"do-not-switch-to-hdmi-from-analog", based on some property provided
by the port (is_hdmi=1 or similar). A side benefit here would be that
input and output ports would be treated identically.

(b) Forget about the integration of module-switch-on-port-available
and Bluetooth-HFGW. Similar policies could be integrated in
module-bluetooth-policy. And after all, the integration with
module-switch-on-port-available is difficult anyway (see workaround in
patch v0 19/20).

Cheers,
Mikel