From: "Frédéric Dalleau" <frederic.dalleau@access-company.com>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] [Patch] org.bluez.audio.headset.Connect() to handsfree
Date: Thu, 06 Dec 2007 12:30:28 +0100 [thread overview]
Message-ID: <4757DD54.20607@access-company.com> (raw)
In-Reply-To: <4757DCBD.40602@access-company.com>
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]
Here is the patch. :/
Frederic
Frédéric Dalleau wrote:
> Hello,
>
> As of today, when calling org.bluez.audio.headset.Connect(), the hfp
> profile is searched only if the headset->hfp_handle is initialized.
> This member variable is initialized upon CreateDevice the first time the
> device is created (during resolve_services).
> The variable is not initialized when the audio service is restarted, so
> after restarting audio service, it is no longer possible to connect to hfp.
>
> The attached patch fix the problem as follow : first search the hfp
> profile handle, then search an hsp profile handle, by getting rfcomm
> channel to connect to.
>
> It is based against latest git tree.
>
> Frederic.
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
[-- Attachment #2: handsfreeconnect.patch --]
[-- Type: text/x-patch, Size: 2347 bytes --]
diff --git a/audio/headset.c b/audio/headset.c
index 6cb5406..b32b61b 100644
--- a/audio/headset.c
+++ b/audio/headset.c
@@ -111,6 +111,7 @@ struct headset {
};
static int rfcomm_connect(struct device *device, struct pending_connect *c);
+static int get_handles(struct device *device, struct pending_connect *c);
static void pending_connect_free(struct pending_connect *c)
{
@@ -640,11 +641,21 @@ static void get_record_reply(DBusPendingCall *call, void *data)
goto failed_not_supported;
}
- if ((uuid.type == SDP_UUID32 &&
+ if (hs->type == SVC_HEADSET &&
+ ((uuid.type == SDP_UUID32 &&
uuid.value.uuid32 != HEADSET_SVCLASS_ID) ||
(uuid.type == SDP_UUID16 &&
- uuid.value.uuid16 != HEADSET_SVCLASS_ID)) {
- error("Service classes did not contain the expected UUID");
+ uuid.value.uuid16 != HEADSET_SVCLASS_ID))) {
+ error("Service classes did not contain the expected UUID for hsp");
+ goto failed_not_supported;
+ }
+
+ if (hs->type == SVC_HANDSFREE &&
+ ((uuid.type == SDP_UUID32 &&
+ uuid.value.uuid32 != HANDSFREE_SVCLASS_ID) ||
+ (uuid.type == SDP_UUID16 &&
+ uuid.value.uuid16 != HANDSFREE_SVCLASS_ID))) {
+ error("Service classes did not contain the expected UUID for hfp");
goto failed_not_supported;
}
@@ -750,7 +761,17 @@ static void get_handles_reply(DBusPendingCall *call, void *data)
}
if (array_len < 1) {
- debug("No record handles found");
+
+ if(hs->type == SVC_HANDSFREE) {
+ debug("No record handles found for hfp");
+ hs->type = SVC_HEADSET;
+ get_handles(device, c);
+ dbus_message_unref(reply);
+ return;
+ }
+
+ debug("No record handles found for hsp");
+
if (c->msg)
error_not_supported(device->conn, c->msg);
goto failed;
@@ -785,6 +806,7 @@ static void get_handles_reply(DBusPendingCall *call, void *data)
}
dbus_pending_call_set_notify(pending, get_record_reply, device, NULL);
+
dbus_pending_call_unref(pending);
dbus_message_unref(msg);
dbus_message_unref(reply);
@@ -862,7 +884,7 @@ static int rfcomm_connect(struct device *device, struct pending_connect *c)
if (!g_slist_find(hs->pending, c))
hs->pending = g_slist_append(hs->pending, c);
- hs->type = hs->hfp_handle ? SVC_HANDSFREE : SVC_HEADSET;
+ hs->type = SVC_HANDSFREE;
if (hs->state == HEADSET_STATE_DISCONNECTED)
return get_handles(device, c);
[-- Attachment #3: Type: text/plain, Size: 309 bytes --]
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
[-- Attachment #4: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2007-12-06 11:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-06 11:27 [Bluez-devel] [Patch] org.bluez.audio.headset.Connect() to handsfree Frédéric Dalleau
2007-12-06 11:30 ` Frédéric Dalleau [this message]
2007-12-06 11:40 ` Marcel Holtmann
2007-12-06 15:16 ` Frédéric Dalleau
2007-12-07 14:02 ` Frédéric Dalleau
2007-12-11 15:44 ` [Bluez-devel] [Patch] Service Level Connection for HFP Alok
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4757DD54.20607@access-company.com \
--to=frederic.dalleau@access-company.com \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.