I agree, that the core logic shouldn't be polluted with phone
workarounds. This is especially true when the quirks somehow interfere
or modify the standard path. Having said this, I'd consider this fix
general enough to justify it's integration in the standard driver, since
the policy makes sense for any phone (mis)behaving this way, keeping the
phone specific quirks to an absolute minimum.
You can extend this justification logic to any mis-behavior. We have to
draw a line somewhere.
I know that the N9 is the only phone that has seen this problem so
but the problem will occur with every phone that doesn't "atomically"
change the CLCC list the moment it reports an indicator change (+CIEV).
Our motto here is 'We do not deal with hypothetical situations'. So
unless you find another phone that behaves in this manner, lets try not
to speculate ;)
As described in the commit message the phone already told the HF that
has set up an outgoing call (or that it's already alerting). The only
thing missing is the detailed information about the call, which is
retrieved using the AT+CLCC request.
So in this case I think it's valid to generally try to fill in the
missing information by issuing another AT+CLCC request. Otherwise the
call will be alerting and although the phone has reported all indicator
changes to oFono, we won't be able to reasonably control it from HF side.
I disagree. However, I do think we need to get started on the HFP