Closed Bug 925663 Opened 9 years ago Closed 9 years ago

Macro IS_HEADSET() can't be used to decide which profile connection should be established, HFP or HSP.


(Firefox OS Graveyard :: Bluetooth, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:koi+, firefox25 wontfix, firefox26 fixed, firefox27 fixed, b2g-v1.2 fixed)

blocking-b2g koi+
Tracking Status
firefox25 --- wontfix
firefox26 --- fixed
firefox27 --- fixed
b2g-v1.2 --- fixed


(Reporter: echou, Assigned: echou)


(Keywords: regression)


(2 files, 1 obsolete file)

Symptom: Only HSP connection would be established when I tried to connect with my Bluetooth headset (Nokia BH-503).
Build Info: latest gecko:m-c/gaia:master
Impact: Users can't normally use their Bluetooth headset.

In m-c, macro IS_HEADSET() has been used to decide which profile connection should be established, HFP or HSP. However, it can't be used this way.

According to HFP and HSP spec, in section "Link Control (LC) Interoperability Requirements", "Audio" bit in the Service Class field should be set for both specs, and that's a convenient way for AG to distinguish if the device is an Audio device or not while inquiring. The only difference for HFP and HSP is the Minor Device class field. In HFP, it should be set to "Hands-Free"; in HSP, it should be set to "Headset". Nevertheless, in HSP spec 1.2, it mentions that "The Device Class fields should not be used as filters since many devices support multiple profiles." In other words, even if there is a Bluetooth headset and only "Headset" is set to its Device Class field, it doesn't mean that it has no HFP service.
This is a regression of bug 906305. Nominate as koi+.
blocking-b2g: --- → koi?
Keywords: regression
Assignee: nobody → echou
Severity: normal → major
Already tested on PTS. (HFP:3 cases / HSP:2 cases)
Attachment #815785 - Flags: review?(gyeh)
Comment on attachment 815785 [details] [diff] [review]
patch 1: v1: Establish HSP connection if and only if HFP service record couldn't be found

Review of attachment 815785 [details] [diff] [review]:

Since the values of major/minor device class are not well-defined in spec, it would be a good idea that we try to connect HFP/HSP without them. So, r+'d.

Please see following suggestions.

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +994,3 @@
>    if (NS_FAILED(bs->GetServiceChannel(aDeviceAddress, uuid, this))) {

It seems like that we report this error string in two cases.

First, we failed to send an async request to dbus.
Second, the service channel returned by dbus is incorrent.

Can we use different error strings for distinguishing these two cases?

This should be the case 1.

@@ +1523,5 @@
> +    // try to create HSP connection instead.
> +    nsString hspUuid;
> +    BluetoothUuidHelper::GetString(BluetoothServiceClass::HEADSET, hspUuid);
> +
> +    if (aServiceUuid.Equals(hspUuid) ||

This should be case 2.

@@ +1524,5 @@
> +    nsString hspUuid;
> +    BluetoothUuidHelper::GetString(BluetoothServiceClass::HEADSET, hspUuid);
> +
> +    if (aServiceUuid.Equals(hspUuid) ||
> +        NS_FAILED(bs->GetServiceChannel(aDeviceAddress, hspUuid, this))) {

This should be the case 1.
Attachment #815785 - Flags: review?(gyeh) → review+
Attachment #815785 - Attachment is obsolete: true
Closed: 9 years ago
Resolution: --- → FIXED
* patch for mozilla-aurora
triage: koi+ for regression
blocking-b2g: koi? → koi+
You need to log in before you can comment on or make changes to this bug.