Hi Timo,
I agree, that the core logic shouldn't be polluted with phone specific 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 far, 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 it 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 quirks framework.
Regards, -Denis _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
