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

[Tanu Kaskinen]

On Wed, 2012-08-22 at 14:27 +0200, Mikel Astiz wrote:
> 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).

Disclaimer: I don't know what the problem with HFGW is, so basically I
don't know what I'm talking about... Anyway, b) sounds better to me.
module-switch-on-port-available seems like a hack to me (it may be the
best that we can do within the limitations of the infrastructure,
though, so I'm not berating David who wrote it). If it's not suitable
for Bluetooth, I think module-bluetooth-policy should replace
module-switch-on-port-available for the Bluetooth ports.

I'm not sure how the "replacing" should be implemented, though.
Returning PA_HOOK_STOP from module-bluetooth-policy would prevent
module-switch-on-port-available from doing anything, but it would also
prevent all other modules from doing anything. Currently
module-switch-on-port-available is the only thing that uses
PA_CORE_HOOK_PORT_AVAILABLE_CHANGED, so there won't be any immediate
bugs, but there's a risk for future bugs, so if someone can think of a
better way to do it, please tell...

-- 
Tanu