> > I don't see how that's a bug. hs->hfp_active should be true only when we > are connected to HFP. server_is_enabled(src, HANDSFREE_SVCLASS_ID) is > supposed to return true if HFP support is enabled in general. These are > two separate things (we could be connected to HSP even though HFP support > is enabled if the headset only supports HSP, i.e. hs->hfp_handle == 0 in > this case). > Let me describe how the bug is triggered by the following steps in our lab: 1 at HFP AW side bluetoothd is started, and headset_init() is called. However btd_device_get_record() returns NULL, so hs->hfp_handle is NULL. 2 at HFP HF unit side bluetoothd is started, and initiated connection to HFP AW 3 HFP AW accepts the connection, and headset_connect_cb() is called. At this time hs->hfp_handle is NULL, so hs->hfp_active is set to FALSE. This way the bug is triggered: a real HFP connection is initiated by HFP HF unit, but hs->hfp_active is set to FALSE by HFP AW. It seems that this patch is not a real fix, could you share the ideas of fixing this bug? Thanks, Forrest -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
