Linux bluetooth development
 help / color / mirror / Atom feed
* [PATCH 6/6] Fix problem with double numer in call log
From: Rafał Michalski @ 2010-09-28 11:09 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Rafał Michalski

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: 0006-Fix-problem-with-double-number-in-call-log.patch --]
[-- Type: text/x-patch, Size: 2013 bytes --]

From be0a6ef8affbc3c1d0b1fbd94b1e78cd2c94f17c Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:07:48 +0200
Subject: [PATCH 6/6] Fix problem with double number in call log

Previously after downloading call log there was two times the same number
for call binded with phonebook - one HOME/WORK type and second OTHER type
in downloaded vCard structure. Now there is only one number with proper
type (HOME or WORK).
---
 plugins/phonebook-tracker.c |   18 ++++++++++++++++--
 plugins/vcard.c             |    1 -
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index ab874e5..2d94bc6 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -774,10 +774,24 @@ static struct phonebook_contact *find_contact(GSList *contacts, const char *id)
 static struct phonebook_number *find_phone(GSList *numbers, const char *phone,
 								int type)
 {
-	GSList *l;
+	GSList *l = numbers;
 	struct phonebook_number *pb_num;
 
-	for (l = numbers; l; l = l->next) {
+	if (g_slist_length(l) == 1 && (pb_num = l->data) &&
+					g_strcmp0(pb_num->tel, phone) == 0) {
+
+		if ((type == TEL_TYPE_HOME || type == TEL_TYPE_WORK) &&
+					pb_num->type == TEL_TYPE_OTHER)	{
+			pb_num->type = type;
+			return pb_num;
+		}
+
+		if (type == TEL_TYPE_OTHER && (pb_num->type == TEL_TYPE_HOME ||
+					pb_num->type == TEL_TYPE_WORK))
+			return pb_num;
+	}
+
+	for (; l; l = l->next) {
 		pb_num = l->data;
 		/* Returning phonebook number if phone values and type values
 		 * are equal */
diff --git a/plugins/vcard.c b/plugins/vcard.c
index c720954..41f9fbd 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -452,7 +452,6 @@ static void vcard_printf_datetime(GString *vcards,
 static void vcard_printf_end(GString *vcards)
 {
 	vcard_printf(vcards, "END:VCARD");
-	vcard_printf(vcards, "");
 }
 
 void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
-- 
1.6.3.3


^ permalink raw reply related

* [PATCH 5/6] Binding cch call log with phonebook
From: Rafał Michalski @ 2010-09-28 11:05 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Rafał Michalski

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: 0005-Binding-cch-call-log-with-phonebook.patch --]
[-- Type: text/x-patch, Size: 3634 bytes --]

From 394300a522192fb40629c966ce7ac2c6d4b7d322 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:06:47 +0200
Subject: [PATCH 5/6] Binding cch call log with phonebook

After incoming/missed/outgoing call is done by/to number from phonebook
then combined call history will be shown with data about caller -
downloaded in vCard structure.
---
 plugins/phonebook-tracker.c |   67 ++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 66 insertions(+), 1 deletions(-)

diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 5752536..ab874e5 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -337,18 +337,83 @@
 	"nmo:isSent(?call) nmo:isAnswered(?call) ?x "			\
 	"WHERE { "							\
 	"{ "								\
+		"{ "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?h . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:to ?x ; "						\
+		"nmo:isSent true . "					\
+		"?c a nco:PersonContact . "				\
+		"?c nco:hasPhoneNumber ?h . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"OPTIONAL { "						\
+			"?c nco:hasAffiliation ?a . "			\
+			"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "	\
+			"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "	\
+			"OPTIONAL { ?a nco:org ?o . } "			\
+		"} "							\
+		"} UNION { "						\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?w . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:to ?x ; "						\
+		"nmo:isSent true . "					\
+		"?c a nco:PersonContact . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"?c nco:hasAffiliation ?a . "				\
+		"?a nco:hasPhoneNumber ?w . "				\
+		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
+		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
+		"OPTIONAL { ?a nco:org ?o . } "				\
+		"} UNION { "						\
 		"?x a nco:Contact . "					\
 		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
 		"nmo:to ?x ; "						\
 		"nmo:isSent true . "					\
+		"} "							\
 	"} UNION { "							\
+		"{ "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?h . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:from ?x ; "					\
+		"nmo:isSent false . "					\
+		"?c a nco:PersonContact . "				\
+		"?c nco:hasPhoneNumber ?h . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"OPTIONAL { "						\
+			"?c nco:hasAffiliation ?a . "			\
+			"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "	\
+			"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "	\
+			"OPTIONAL { ?a nco:org ?o . } "			\
+		"} "							\
+		"} UNION { "						\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?w . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:from ?x ; "					\
+		"nmo:isSent false . "					\
+		"?c a nco:PersonContact . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"?c nco:hasAffiliation ?a . "				\
+		"?a nco:hasPhoneNumber ?w . "				\
+		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
+		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
+		"OPTIONAL { ?a nco:org ?o . } "				\
+		"} UNION { "						\
 		"?x a nco:Contact . "					\
 		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
 		"nmo:from ?x ; "					\
 		"nmo:isSent false . "					\
-	"} } ORDER BY DESC(nmo:receivedDate(?call))"
+		"} "							\
+	"} "								\
+	"} ORDER BY DESC(nmo:receivedDate(?call)) "
 
 #define COMBINED_CALLS_LIST						\
 	"SELECT ?c nco:nameFamily(?c) nco:nameGiven(?c) "		\
-- 
1.6.3.3


^ permalink raw reply related

* [PATCH 4/6] Binding och call log with phonebook
From: Rafał Michalski @ 2010-09-28 11:02 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Rafał Michalski

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: 0004-Binding-och-call-log-with-phonebook.patch --]
[-- Type: text/x-patch, Size: 2290 bytes --]

From 08079d74cd123ae62e250425ec46496e23635e55 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:05:52 +0200
Subject: [PATCH 4/6] Binding och call log with phonebook

After outgoing call is done to number from phonebook then outgoing call
history will be shown with data about caller - downloaded in vCard
structure.
---
 plugins/phonebook-tracker.c |   34 +++++++++++++++++++++++++++++++++-
 1 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 50b2896..5752536 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -268,12 +268,44 @@
 	"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) "	\
 	"nmo:isSent(?call) nmo:isAnswered(?call) ?x "			\
 	"WHERE { "							\
+	"{ "								\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?h . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:to ?x ; "						\
+		"nmo:isSent true . "					\
+		"?c a nco:PersonContact . "				\
+		"?c nco:hasPhoneNumber ?h . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"OPTIONAL { "						\
+			"?c nco:hasAffiliation ?a . "			\
+			"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "	\
+			"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "	\
+			"OPTIONAL { ?a nco:org ?o . } "			\
+		"} "							\
+	"} UNION { "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?w . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:to ?x ; "						\
+		"nmo:isSent true . "					\
+		"?c a nco:PersonContact . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"?c nco:hasAffiliation ?a . "				\
+		"?a nco:hasPhoneNumber ?w . "				\
+		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
+		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
+		"OPTIONAL { ?a nco:org ?o . } "				\
+	"} UNION { "							\
 		"?x a nco:Contact . "					\
 		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
 		"nmo:to ?x ; "						\
 		"nmo:isSent true . "					\
-	"} ORDER BY DESC(nmo:sentDate(?call))"
+	"} "								\
+	"} ORDER BY DESC(nmo:sentDate(?call)) "
 
 #define OUTGOING_CALLS_LIST						\
 	"SELECT ?c nco:nameFamily(?c) "					\
-- 
1.6.3.3


^ permalink raw reply related

* [PATCH 3/6] Binding ich call log with phonebook
From: Rafał Michalski @ 2010-09-28 11:01 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Rafał Michalski

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: 0003-Binding-ich-call-log-with-phonebook.patch --]
[-- Type: text/x-patch, Size: 2440 bytes --]

From d54b95be067fad58674730c5dee78f413ea3ae5e Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:05:12 +0200
Subject: [PATCH 3/6] Binding ich call log with phonebook

After incoming call is done by number from phonebook then incoming call
history will be shown with data about caller - downloaded in vCard
structure.
---
 plugins/phonebook-tracker.c |   38 ++++++++++++++++++++++++++++++++++++--
 1 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index faa3281..50b2896 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -196,13 +196,47 @@
 	"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) "	\
 	"nmo:isSent(?call) nmo:isAnswered(?call) ?x "			\
 	"WHERE { "							\
+	"{ "								\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?h . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:from ?x ; "					\
+		"nmo:isSent false ; "					\
+		"nmo:isAnswered true . "				\
+		"?c a nco:PersonContact . "				\
+		"?c nco:hasPhoneNumber ?h . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"OPTIONAL { "						\
+			"?c nco:hasAffiliation ?a . "			\
+			"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "	\
+			"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "	\
+			"OPTIONAL { ?a nco:org ?o . } "			\
+		"} "							\
+	"} UNION { "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?w . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:from ?x ; "					\
+		"nmo:isSent false ; "					\
+		"nmo:isAnswered true . "				\
+		"?c a nco:PersonContact . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"?c nco:hasAffiliation ?a . "				\
+		"?a nco:hasPhoneNumber ?w . "				\
+		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
+		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
+		"OPTIONAL { ?a nco:org ?o . } "				\
+	"} UNION { "							\
 		"?x a nco:Contact . "					\
 		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
 		"nmo:from ?x ; "					\
 		"nmo:isSent false ; "					\
-		"nmo:isAnswered true ."					\
-	"} ORDER BY DESC(nmo:receivedDate(?call))"
+		"nmo:isAnswered true . "				\
+	"} "								\
+	"} ORDER BY DESC(nmo:receivedDate(?call)) "
 
 #define INCOMING_CALLS_LIST						\
 	"SELECT ?c nco:nameFamily(?c) "					\
-- 
1.6.3.3


^ permalink raw reply related

* [PATCH 2/6] Binding mch call log with phonebook
From: Rafał Michalski @ 2010-09-28 10:59 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Rafał Michalski

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: 0002-Binding-mch-call-log-with-phonebook.patch --]
[-- Type: text/x-patch, Size: 2437 bytes --]

From e5a8c8ae9923fefc358f7e9e9a1ba88f30ed4662 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:04:21 +0200
Subject: [PATCH 2/6] Binding mch call log with phonebook

After missed call is done by number from phonebook then missed call
history will be shown with data about caller - downloaded in vCard
structure.
---
 plugins/phonebook-tracker.c |   38 ++++++++++++++++++++++++++++++++++++--
 1 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 5aaa9a8..faa3281 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -124,13 +124,47 @@
 	"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) "	\
 	"nmo:isSent(?call) nmo:isAnswered(?call) ?x "			\
 	"WHERE { "							\
+	"{ "								\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?h . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:from ?x ; "					\
+		"nmo:isSent false ; "					\
+		"nmo:isAnswered false . "				\
+		"?c a nco:PersonContact . "				\
+		"?c nco:hasPhoneNumber ?h . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"OPTIONAL { "						\
+			"?c nco:hasAffiliation ?a . "			\
+			"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "	\
+			"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "	\
+			"OPTIONAL { ?a nco:org ?o . } "			\
+		"} "							\
+	"} UNION { "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?w . "				\
+		"?call a nmo:Call ; "					\
+		"nmo:from ?x ; "					\
+		"nmo:isSent false ; "					\
+		"nmo:isAnswered false . "				\
+		"?c a nco:PersonContact . "				\
+		"OPTIONAL { ?c nco:hasEmailAddress ?e . } "		\
+		"OPTIONAL { ?c nco:hasPostalAddress ?p . } "		\
+		"?c nco:hasAffiliation ?a . "				\
+		"?a nco:hasPhoneNumber ?w . "				\
+		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
+		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
+		"OPTIONAL { ?a nco:org ?o . } "				\
+	"} UNION { "							\
 		"?x a nco:Contact . "					\
 		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
 		"nmo:from ?x ; "					\
 		"nmo:isSent false ; "					\
-		"nmo:isAnswered false ."				\
-	"} ORDER BY DESC(nmo:receivedDate(?call))"
+		"nmo:isAnswered false . "				\
+	"} "								\
+	"} ORDER BY DESC(nmo:receivedDate(?call)) "
 
 #define MISSED_CALLS_LIST						\
 	"SELECT ?c nco:nameFamily(?c) "					\
-- 
1.6.3.3


^ permalink raw reply related

* [PATCH 1/6] Changing default type of call from call log
From: Rafał Michalski @ 2010-09-28 10:56 UTC (permalink / raw)
  To: linux-bluetooth

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: 0001-Changing-default-type-of-call-from-call-log.patch --]
[-- Type: text/x-patch, Size: 11078 bytes --]

From e93ee56b1322c4fbf37885b99bc4e976b760b12d Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:03:22 +0200
Subject: [PATCH 1/6] Changing default type of call from call log

Previously after downloading call log all calls had HOME type as default.
Now this type is OTHER - it will be used when connection is made
with number which is out of phonebook. To solve this issue extending
number of columns and queries of database was needed especially
(one field in database query was added).
---
 plugins/phonebook-tracker.c |  140 ++++++++++++-------------------------------
 plugins/vcard.c             |    4 +-
 2 files changed, 40 insertions(+), 104 deletions(-)

diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 3161927..5aaa9a8 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -43,16 +43,17 @@
 #define TRACKER_RESOURCES_INTERFACE "org.freedesktop.Tracker1.Resources"
 
 #define TRACKER_DEFAULT_CONTACT_ME "http://www.semanticdesktop.org/ontologies/2007/03/22/nco#default-contact-me"
-#define CONTACTS_ID_COL 37
-#define PULL_QUERY_COL_AMOUNT 38
+#define CONTACTS_ID_COL 38
+#define PULL_QUERY_COL_AMOUNT 39
 #define COL_HOME_NUMBER 0
 #define COL_HOME_EMAIL 7
 #define COL_WORK_NUMBER 8
 #define COL_FAX_NUMBER 16
 #define COL_WORK_EMAIL 17
-#define COL_DATE 34
-#define COL_SENT 35
-#define COL_ANSWERED 36
+#define COL_OTHER_NUMBER 34
+#define COL_DATE 35
+#define COL_SENT 36
+#define COL_ANSWERED 37
 #define ADDR_FIELD_AMOUNT 7
 
 #define CONTACTS_QUERY_ALL						\
@@ -68,7 +69,8 @@
 	"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) "		\
 	"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) "	\
 	"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) "	\
-	"nco:title(?a) \"NOTACALL\" \"false\" \"false\" ?c "		\
+	"nco:title(?a) nco:phoneNumber(?t) "				\
+	"\"NOTACALL\" \"false\" \"false\" ?c "				\
 	"WHERE { "							\
 		"?c a nco:PersonContact . "				\
 	"OPTIONAL { ?c nco:hasPhoneNumber ?h . 				\
@@ -113,35 +115,21 @@
 	"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) "		\
 	"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) "	\
 	"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) "	\
-	"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) "	\
+	"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
 	"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) "	\
 	"nco:photo(?c) nco:fullname(?o) nco:department(?a) "		\
 	"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) "		\
 	"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) "	\
 	"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) "	\
-	"nco:title(?a) nmo:receivedDate(?call) "			\
-	"nmo:isSent(?call) nmo:isAnswered(?call) ?c "			\
+	"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) "	\
+	"nmo:isSent(?call) nmo:isAnswered(?call) ?x "			\
 	"WHERE { "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
-		"nmo:from ?c ; "					\
+		"nmo:from ?x ; "					\
 		"nmo:isSent false ; "					\
 		"nmo:isAnswered false ."				\
-		"?c a nco:Contact . "					\
-	"OPTIONAL { ?c nco:hasPhoneNumber ?h . "			\
-		"OPTIONAL {"						\
-		"?h a nco:FaxNumber ; "					\
-		"nco:phoneNumber ?f . "					\
-		"}"							\
-	"} "								\
-	"OPTIONAL { ?c nco:hasEmailAddress ?e . } "			\
-	"OPTIONAL { ?c nco:hasPostalAddress ?p . } "			\
-	"OPTIONAL { "							\
-		"?c nco:hasAffiliation ?a . "				\
-		"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " 		\
-		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
-		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
-		"OPTIONAL { ?a nco:org ?o . } "				\
-	"} "								\
 	"} ORDER BY DESC(nmo:receivedDate(?call))"
 
 #define MISSED_CALLS_LIST						\
@@ -165,35 +153,21 @@
 	"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) "		\
 	"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) "	\
 	"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) "	\
-	"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) "	\
+	"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
 	"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) "	\
 	"nco:photo(?c) nco:fullname(?o) nco:department(?a) "		\
 	"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) "		\
 	"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) "	\
 	"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) "	\
-	"nco:title(?a) nmo:receivedDate(?call) "			\
-	"nmo:isSent(?call) nmo:isAnswered(?call) ?c "			\
+	"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) "	\
+	"nmo:isSent(?call) nmo:isAnswered(?call) ?x "			\
 	"WHERE { "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
-		"nmo:from ?c ; "					\
+		"nmo:from ?x ; "					\
 		"nmo:isSent false ; "					\
 		"nmo:isAnswered true ."					\
-		"?c a nco:Contact . "					\
-	"OPTIONAL { ?c nco:hasPhoneNumber ?h . "			\
-		"OPTIONAL {"						\
-		"?h a nco:FaxNumber ; "					\
-		"nco:phoneNumber ?f . "					\
-		"}"							\
-	"} "								\
-	"OPTIONAL { ?c nco:hasEmailAddress ?e . } "			\
-	"OPTIONAL { ?c nco:hasPostalAddress ?p . } "			\
-	"OPTIONAL { "							\
-		"?c nco:hasAffiliation ?a . "				\
-		"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " 		\
-		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
-		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
-		"OPTIONAL { ?a nco:org ?o . } "				\
-	"} "								\
 	"} ORDER BY DESC(nmo:receivedDate(?call))"
 
 #define INCOMING_CALLS_LIST						\
@@ -217,34 +191,20 @@
 	"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) "		\
 	"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) "	\
 	"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) "	\
-	"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew)"	\
+	"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew)"	\
 	"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) "	\
 	"nco:photo(?c) nco:fullname(?o) nco:department(?a) "		\
 	"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) "		\
 	"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) "	\
 	"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) "	\
-	"nco:title(?a) nmo:receivedDate(?call) "			\
-	"nmo:isSent(?call) nmo:isAnswered(?call) ?c "			\
+	"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) "	\
+	"nmo:isSent(?call) nmo:isAnswered(?call) ?x "			\
 	"WHERE { "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
-		"nmo:to ?c ; "						\
+		"nmo:to ?x ; "						\
 		"nmo:isSent true . "					\
-		"?c a nco:Contact . "					\
-	"OPTIONAL { ?c nco:hasPhoneNumber ?h . "			\
-		"OPTIONAL {"						\
-		"?h a nco:FaxNumber ; "					\
-		"nco:phoneNumber ?f . "					\
-		"}"							\
-	"} "								\
-	"OPTIONAL { ?c nco:hasEmailAddress ?e . } "			\
-	"OPTIONAL { ?c nco:hasPostalAddress ?p . } "			\
-	"OPTIONAL { "							\
-		"?c nco:hasAffiliation ?a . "				\
-		"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " 		\
-		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
-		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
-		"OPTIONAL { ?a nco:org ?o . } "				\
-	"} "								\
 	"} ORDER BY DESC(nmo:sentDate(?call))"
 
 #define OUTGOING_CALLS_LIST						\
@@ -267,53 +227,27 @@
 	"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) "		\
 	"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) "	\
 	"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) "	\
-	"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) "	\
+	"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
 	"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) "	\
 	"nco:photo(?c) nco:fullname(?o) nco:department(?a) "		\
 	"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) "		\
 	"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) "	\
 	"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) "	\
-	"nco:title(?a) nmo:receivedDate(?call) "			\
-	"nmo:isSent(?call) nmo:isAnswered(?call) ?c "			\
+	"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) "	\
+	"nmo:isSent(?call) nmo:isAnswered(?call) ?x "			\
 	"WHERE { "							\
 	"{ "								\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
-		"nmo:to ?c ; "						\
+		"nmo:to ?x ; "						\
 		"nmo:isSent true . "					\
-		"?c a nco:Contact . "					\
-	"OPTIONAL { ?c nco:hasPhoneNumber ?h . "			\
-		"OPTIONAL {"						\
-		"?h a nco:FaxNumber ; "					\
-		"nco:phoneNumber ?f . "					\
-		"}"							\
-	"} "								\
-	"OPTIONAL { ?c nco:hasEmailAddress ?e . } "			\
-	"OPTIONAL { ?c nco:hasPostalAddress ?p . } "			\
-	"OPTIONAL { ?c nco:hasAffiliation ?a . "			\
-		"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " 		\
-		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
-		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
-		"OPTIONAL { ?a nco:org ?o . } "				\
-	"} "								\
 	"} UNION { "							\
+		"?x a nco:Contact . "					\
+		"?x nco:hasPhoneNumber ?t . "				\
 		"?call a nmo:Call ; "					\
-		"nmo:from ?c ; "					\
+		"nmo:from ?x ; "					\
 		"nmo:isSent false . "					\
-		"?c a nco:Contact . "					\
-	"OPTIONAL { ?c nco:hasPhoneNumber ?h . "			\
-		"OPTIONAL {"						\
-		"?h a nco:FaxNumber ; "					\
-		"nco:phoneNumber ?f . "					\
-		"}"							\
-	"} "								\
-	"OPTIONAL { ?c nco:hasEmailAddress ?e . } "			\
-	"OPTIONAL { ?c nco:hasPostalAddress ?p . } "			\
-	"OPTIONAL { ?c nco:hasAffiliation ?a . "			\
-		"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " 		\
-		"OPTIONAL { ?a nco:hasEmailAddress ?ew . } "		\
-		"OPTIONAL { ?a nco:hasPostalAddress ?pw . } "		\
-		"OPTIONAL { ?a nco:org ?o . } "				\
-	"} "								\
 	"} } ORDER BY DESC(nmo:receivedDate(?call))"
 
 #define COMBINED_CALLS_LIST						\
@@ -349,7 +283,8 @@
 	"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) "		\
 	"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) "	\
 	"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(<%s>) "	\
-	"nco:title(?a) \"NOTACALL\" \"false\" \"false\" <%s> "		\
+	"nco:title(?a) nco:phoneNumber(?t) "				\
+	"\"NOTACALL\" \"false\" \"false\" <%s> "			\
 	"WHERE { "							\
 		"<%s> a nco:Contact . "					\
 	"OPTIONAL { <%s> nco:hasPhoneNumber ?h . 			\
@@ -875,6 +810,7 @@ add_numbers:
 	add_phone_number(contact, reply[COL_HOME_NUMBER], TEL_TYPE_HOME);
 	add_phone_number(contact, reply[COL_WORK_NUMBER], TEL_TYPE_WORK);
 	add_phone_number(contact, reply[COL_FAX_NUMBER], TEL_TYPE_FAX);
+	add_phone_number(contact, reply[COL_OTHER_NUMBER], TEL_TYPE_OTHER);
 
 	/* Adding emails */
 	add_email(contact, reply[COL_HOME_EMAIL], EMAIL_TYPE_HOME);
diff --git a/plugins/vcard.c b/plugins/vcard.c
index bc22177..c720954 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -241,9 +241,9 @@ static void vcard_printf_number(GString *vcards, uint8_t format,
 		break;
 	case TEL_TYPE_OTHER:
 		if (format == FORMAT_VCARD21)
-			category_string = "VOICE";
+			category_string = "OTHER;VOICE";
 		else if (format == FORMAT_VCARD30)
-			category_string = "TYPE=VOICE";
+			category_string = "TYPE=OTHER;TYPE=VOICE";
 		break;
 	}
 
-- 
1.6.3.3


^ permalink raw reply related

* How to send stream via obexd without ending request
From: Lukasz Pawlik @ 2010-09-28 10:14 UTC (permalink / raw)
  To: linux-bluetooth

Hi,

I want to stream data immediately after they appear and wait for next 
part. So far I didn't manage to find a way how to do this properly. 
Returning error EAGAIN from my read function leads to canceling request 
and this is something I don't want to do. The other way I was able to 
find is returning value > 0 from read function until last part of data 
appear. Obexd will stream data when buffer exceed allocated memory chunk 
and return to read more data. This is no solution because it forces 
obexd to send empty streams. Does anyone knows how to solve this problem ?

-- 
Łukasz Pawlik

^ permalink raw reply

* [PATCH] Add checking for agent reply state in adapter
From: Radoslaw Jablonski @ 2010-09-28  9:17 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Radoslaw Jablonski

Added checking for agent reply state before cancelling agent in
session_free(..). This check is needed to ensure that memory for
agent request will be freed only once (In that case, free on this
request is called later in the end of agent_reply func)
---
 src/adapter.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/src/adapter.c b/src/adapter.c
index 0e9be5f..c122f82 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -82,6 +82,7 @@ struct session_req {
 	guint			id;		/* Listener id */
 	uint8_t			mode;		/* Requested mode */
 	int			refcount;	/* Session refcount */
+	gboolean		is_reply;	/* Agent reply is present */
 };
 
 struct service_auth {
@@ -757,7 +758,9 @@ static void session_free(struct session_req *req)
 
 	if (req->msg) {
 		dbus_message_unref(req->msg);
-		if (req->mode && req->adapter->agent)
+		/* if initial reply is present, we shouldn't cancel agent,
+		 * because it will be done later in agent_reply function */
+		if (!req->is_reply && req->mode && req->adapter->agent)
 			agent_cancel(req->adapter->agent);
 	}
 
@@ -794,6 +797,7 @@ static void confirm_mode_cb(struct agent *agent, DBusError *derr, void *data)
 	int err;
 	DBusMessage *reply;
 
+	req->is_reply = TRUE;
 	if (derr && dbus_error_is_set(derr)) {
 		reply = dbus_message_new_error(req->msg, derr->name,
 						derr->message);
-- 
1.7.0.4


^ permalink raw reply related

* Re: [PATCH 6/6] This patch adds support for using the ST-Ericsson CG2900
From: Par-Gunnar Hjalmdahl @ 2010-09-28  9:14 UTC (permalink / raw)
  To: Gustavo F. Padovan
  Cc: linux-bluetooth, linux-kernel, linus.walleij, Pavan Savoy
In-Reply-To: <20100927164502.GB30310@vigoh>

Hi Gustavo,

Thanks for your comments. See below for answers.

/P-G

2010/9/27 Gustavo F. Padovan <padovan@profusion.mobi>:
> Hi Par-Gunnar,
>
> * Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com> [2010-09-24 15:52:16 +0200]:
>
>> This patch adds support for using the ST-Ericsson CG2900
>>  connectivity controller as a driver for the BlueZ Bluetooth
>>  stack.
>>  This patch registers as a driver into the BlueZ framework and, when
>>  opened by BlueZ, it registers as user for bt_cmd, bt_acl, and bt_evt
>>  channels.
>
> First of all your your commit message and subject should be improved.
> The subject should bee something like:
>
> "Bluetooth: Add support for ST-Ericsson CG2900"
>
> and in the commit message you explain the details of the patch.
> And normally we do not use the BlueZ word in kernelspace.
>

OK. This is the first patch I've created within the community and of
course there are bound to be errors... ;-)
Since it was part of a big patch delivery I used quite similar names
across the different patches and I understand that this is an error
since the different patches are targeting different communities.

>>
>> Signed-off-by: Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com>
>> ---
>>  drivers/bluetooth/Kconfig      |    7 +
>>  drivers/bluetooth/Makefile     |    2 +
>>  drivers/bluetooth/cg2900_hci.c |  896 ++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 905 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/bluetooth/cg2900_hci.c
>
> Your patch looks a way complicated to a UART driver. Look at the others
> drivers at drivers/bluetooth/ and see how we implemented other UART
> drivers.
>

Well, mainly that's because it is not a UART driver. It is a driver
against CG2900 which currently have only UART as transport but quite
soon will get SPI as transport as well. For this Bluetooth driver the
actual physical transport used is not known. It just knows it has a
reliable transport below which delivers complete Bluetooth packets.

>>
>> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
>> index 02deef4..9ca8d69 100644
>> --- a/drivers/bluetooth/Kconfig
>> +++ b/drivers/bluetooth/Kconfig
>> @@ -219,4 +219,11 @@ config BT_ATH3K
>>         Say Y here to compile support for "Atheros firmware download driver"
>>         into the kernel or say M to compile it as module (ath3k).
>>
>> +config BT_CG2900
>> +     tristate "ST-Ericsson CG2900 driver"
>> +     depends on MFD_CG2900 && BT
>> +     help
>> +       Select if ST-Ericsson CG2900 Connectivity controller shall be used as
>> +       Bluetooth controller for BlueZ.
>> +
>>  endmenu
>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>> index 71bdf13..a479c16 100644
>> --- a/drivers/bluetooth/Makefile
>> +++ b/drivers/bluetooth/Makefile
>> @@ -19,6 +19,8 @@ obj-$(CONFIG_BT_ATH3K)              += ath3k.o
>>  obj-$(CONFIG_BT_MRVL)                += btmrvl.o
>>  obj-$(CONFIG_BT_MRVL_SDIO)   += btmrvl_sdio.o
>>
>> +obj-$(CONFIG_BT_CG2900)              += cg2900_hci.o
>> +
>>  btmrvl-y                     := btmrvl_main.o
>>  btmrvl-$(CONFIG_DEBUG_FS)    += btmrvl_debugfs.o
>>
>> diff --git a/drivers/bluetooth/cg2900_hci.c b/drivers/bluetooth/cg2900_hci.c
>> new file mode 100644
>> index 0000000..de1ada8
>> --- /dev/null
>> +++ b/drivers/bluetooth/cg2900_hci.c
>> @@ -0,0 +1,896 @@
>> +/*
>> + * drivers/bluetooth/cg2900_hci.c
>> + *
>> + * Copyright (C) ST-Ericsson SA 2010
>> + * Authors:
>> + * Par-Gunnar Hjalmdahl (par-gunnar.p.hjalmdahl@stericsson.com) for
>> ST-Ericsson.
>> + * Henrik Possung (henrik.possung@stericsson.com) for ST-Ericsson.
>> + * Josef Kindberg (josef.kindberg@stericsson.com) for ST-Ericsson.
>> + * Dariusz Szymszak (dariusz.xd.szymczak@stericsson.com) for ST-Ericsson.
>> + * Kjell Andersson (kjell.k.andersson@stericsson.com) for ST-Ericsson.
>> + * License terms:  GNU General Public License (GPL), version 2
>> + *
>> + * Linux Bluetooth HCI H:4 Driver for ST-Ericsson CG2900 connectivity
>> controller
>> + * towards the BlueZ Bluetooth stack.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/types.h>
>> +#include <linux/skbuff.h>
>> +#include <asm/byteorder.h>
>> +#include <net/bluetooth/bluetooth.h>
>> +#include <net/bluetooth/hci.h>
>> +#include <net/bluetooth/hci_core.h>
>> +
>> +#include <linux/workqueue.h>
>> +#include <linux/wait.h>
>> +#include <linux/time.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/sched.h>
>> +#include <linux/timer.h>
>> +
>> +#include <linux/mfd/cg2900.h>
>> +#include <mach/cg2900_devices.h>
>> +
>> +/* module_param declared in cg2900_core.c */
>> +extern int cg2900_debug_level;
>
> You don't need that, just use dynamic debug instead
>

Regarding the debug we know we have made an debug implementation that
might be controversial. We have used defines to output debug at
different levels and a module param to control the debug level in
runtime. I know that rest of the Kernel use other ways for debug and
if our way is not accepted we will of course modify the debug in the
driver to use standard Kernel methods.

I personally prefer to use defines because it makes it easy to add a
file name or similar at the start of the printout and also always use
'\n' in the end of each debug line. But if you don't like it that way
we will of course change that as well.

>> +
>> +#define NAME                 "CG2900 HCI"
>> +
>> +/* Debug defines */
>> +#define CG2900_DBG_DATA(fmt, arg...)                         \
>> +do {                                                         \
>> +     if (cg2900_debug_level >= 25)                           \
>> +             printk(KERN_DEBUG NAME " %s: " fmt "\n" , __func__ , ## arg); \
>> +} while (0)
>> +
>> +#define CG2900_DBG(fmt, arg...)                              \
>> +do {                                                         \
>> +     if (cg2900_debug_level >= 20)                           \
>> +             printk(KERN_DEBUG NAME " %s: " fmt "\n" , __func__ , ## arg); \
>> +} while (0)
>> +
>> +#define CG2900_INFO(fmt, arg...)                             \
>> +do {                                                         \
>> +     if (cg2900_debug_level >= 10)                           \
>> +             printk(KERN_INFO NAME ": " fmt "\n" , ## arg); \
>> +} while (0)
>> +
>> +#define CG2900_ERR(fmt, arg...)                                      \
>> +do {                                                         \
>> +     if (cg2900_debug_level >= 1)                            \
>> +             printk(KERN_ERR NAME " %s: " fmt "\n" , __func__ , ## arg); \
>> +} while (0)i
>
> and BT_DBG, BT_INFO, BT_ERR instead of these macros.

OK.

>
>> +
>> +#define CG2900_SET_STATE(__name, __var, __new_state)                 \
>> +do {                                                                 \
>> +     CG2900_DBG("New %s: 0x%X", __name, (uint32_t)__new_state);      \
>> +     __var = __new_state;                                            \
>> +} while (0)
>
> Don't hide your operation with a macro, that is a simple attribution, so
> no need for a macro for that.
>

OK. I prefer to be able to get a printout 'automatically' every time
state is changed, but it is no big issue to do this directly in the
code instead.

>> +
>> +/* HCI device type */
>> +#define HCI_CG2900           HCI_VIRTUAL
>> +
>> +/* Wait for 5 seconds for a response to our requests */
>> +#define RESP_TIMEOUT         5000
>> +
>> +/* State-setting defines */
>> +#define SET_RESET_STATE(__hci_reset_new_state) \
>> +     CG2900_SET_STATE("reset_state", hci_info->reset_state, \
>> +                      __hci_reset_new_state)
>> +#define SET_ENABLE_STATE(__hci_enable_new_state) \
>> +     CG2900_SET_STATE("enable_state", hci_info->enable_state, \
>> +                      __hci_enable_new_state)
>
> Same here.
>

OK.

> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
>

^ permalink raw reply

* Re: Spurious authentication request?
From: Johan Hedberg @ 2010-09-28  8:15 UTC (permalink / raw)
  To: Daniel Örstadius; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikrQ2fAHDZwMncOpNRadjm=tdobvDoas=v5eyxH@mail.gmail.com>

Hi Daniel,

On Mon, Sep 27, 2010, Daniel Örstadius wrote:
> Occasionally when pairing with a headset BlueZ issues what looks
> to be an unnecessary "Authentication Requested" after
> receiving "Auth Complete" and "Simple Pairing Complete".
> 
> 2010-09-22 11:23:45.282348 > HCI Event: Auth Complete (0x06) plen 3
>     status 0x00 handle 2
> 2010-09-22 11:23:45.282378 < HCI Command: Set Connection Encryption
> (0x01|0x0013) plen 3
>     handle 2 encrypt 0x01
> [..]
> 2010-09-22 11:23:45.363646 < HCI Command: Authentication Requested
> (0x01|0x0011) plen 2
>     handle 2
> 
> This request is coming from bonding_connect_cb and occurs if that
> callback happens to be executed before the function
> hcid_dbus_bonding_process_complete (triggered by the auth complete
> event). The order between those functions might have been affected
> by this patch
> 
> http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=be35d00671519b8d92361c2caad9abeedda151f8
> 
> The request for authentication seems to be used for legacy pairing and
> should probably not be made for simple pairing. Also, it might be
> inconsistent that the kernel issues "Authentication Requested" for
> simple pairing, but bluetoothd does it for legacy?
> 
> I guess enclosing the call in a check for legacy pairing would
> work, if that information is or can be made available to
> bluetoothd.
> 
> Have I understood the situation correctly and if so, what would
> be a good way to fix this issue?

The reason why the extra authentication request is there is to deal with
old kernels that do not initiate authentication by themselves. So
checking for SSP vs legacy pairing wouldn't work.

Johan

^ permalink raw reply

* Re: [PATCH] Fix not detecting errors when transferring the last part of the buffer
From: Johan Hedberg @ 2010-09-28  8:10 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1285660345-1819-1-git-send-email-luiz.dentz@gmail.com>

Hi Luiz,

On Tue, Sep 28, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
> 
> The last part has to be flushed in order to sent the remaining buffer as
> a obex packet and detect possible errors.
> ---
>  client/transfer.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)

Thanks. The patch has been pushed upstream.

Johan

^ permalink raw reply

* Re: [PATCH] Fix problem with EIR data when setting the name
From: Johan Hedberg @ 2010-09-28  7:53 UTC (permalink / raw)
  To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=6ORUZLTY28iHn4q6gAi1mMZjqb=Nt7B6zQN2R@mail.gmail.com>

Hi Lukasz,

On Thu, Sep 23, 2010, Lukasz Pawlik wrote:
> Subject: [PATCH] Fix problem with EIR data when setting the name
> 
> Previously changed BT fiendly name was not reflected until BT adapter reboot.
> This patch fix this problem. Now changed name is reflected without need of
> rebooting adapter.
> ---
>  src/adapter.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/src/adapter.c b/src/adapter.c
> index 9b638cf..0e9be5f 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -1031,6 +1031,7 @@ static DBusMessage *set_name(DBusConnection *conn, DBusMessage *msg,
>  			return failed_strerror(msg, err);
>  
>  		adapter->name_stored = TRUE;
> +		update_ext_inquiry_response(adapter);
>  	}
>  
>  done:

Thanks for the patch. It has now been pushed upstream.

Johan

^ permalink raw reply

* [PATCH] Fix not detecting errors when transferring the last part of the buffer
From: Luiz Augusto von Dentz @ 2010-09-28  7:52 UTC (permalink / raw)
  To: linux-bluetooth

From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>

The last part has to be flushed in order to sent the remaining buffer as
a obex packet and detect possible errors.
---
 client/transfer.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/client/transfer.c b/client/transfer.c
index 58ac265..8ceb36f 100644
--- a/client/transfer.c
+++ b/client/transfer.c
@@ -379,8 +379,10 @@ static void put_xfer_progress(GwObexXfer *xfer, gpointer user_data)
 
 		transfer->filled += len;
 
-		if (transfer->filled == 0)
+		if (transfer->filled == 0) {
+			gw_obex_xfer_flush(xfer, &err);
 			goto done;
+		}
 
 		if (gw_obex_xfer_write(xfer, transfer->buffer,
 					transfer->filled,
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH] Fix headset disconnecting via device disconnect
From: Johan Hedberg @ 2010-09-28  7:47 UTC (permalink / raw)
  To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1285237951-4271-1-git-send-email-ext-jablonski.radoslaw@nokia.com>

Hi Radek,

On Thu, Sep 23, 2010, Radoslaw Jablonski wrote:
> Headsets for proper disconnecting need to disconnect profiles in specified
> order(by ex. disconnect a2dp, then sink and hfp at the end). Instead of
> adding separate callbacks for disconnecting each profile, now adding only
> one callback in audio/device.c for calling audio disconnect functions in
> correct order. New disconnect callback works similarly to dev_disconnect
> from audio/device.c
> ---
>  audio/device.c  |  138 +++++++++++++++++++++++++++++++++++++------------------
>  audio/headset.c |   19 --------
>  audio/sink.c    |   29 ------------
>  audio/source.c  |   33 -------------
>  4 files changed, 93 insertions(+), 126 deletions(-)

Thanks for the patch. It has been pushed upstream with a couple of minor
modifications (which we already discussed offline):

> +	}
> +	else if (new_state == AUDIO_STATE_CONNECTED) {
> +		priv->disconnecting = FALSE;
> +		priv->dc_id = device_add_disconnect_watch(dev->btd_dev,
> +						disconnect_cb, dev, NULL);
> +	}

First of all, coding style: the else if goes on the same line as the {

Secondly, I don't see how disconnecting could be TRUE when going to
CONNECTED state so I removed setting it explicitly to FALSE here.

> +	if (new_state == AUDIO_STATE_DISCONNECTED) {
> +		if (priv->dc_req) {
> +			reply = dbus_message_new_method_return(priv->dc_req);
> +			dbus_message_unref(priv->dc_req);
> +			priv->dc_req = NULL;
> +			g_dbus_send_message(dev->conn, reply);
> +		}
> +		else if (priv->disconnecting)
> +			priv->disconnecting = FALSE;

Again coding style with the else if, and setting the disconnecting flag
to FALSE can be unconditional here in my opinion.

Johan

^ permalink raw reply

* Re: a2dp, myth, pulse
From: Brad Midgley @ 2010-09-28  7:05 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <AANLkTingVh3OaAGQzsxWJQddqrPwgFssMeOq5Rp_DbS6@mail.gmail.com>

Hey

> can avrcp be used to drive mythtv? I've got a setup where the myth
> frontend is rarely the foreground app

So if avrcp were to present events in a /dev/input/eventX device, I
could use inputlircd to connect those events to lirc clients. It might
make it easier if a udev rule created something like /dev/input/avrcp0
so we could find it more easily for the inputlircd config.

And I see now that it is by virtue of the use of liblirc that myth can
get remote events even if it's not the foreground app.

Control is enabled by default in 4.60, is there anything I can check
to see why I don't see any log messages about avrcp, no input device
appear, nothing logged, etc? The main connection is initiated by the
headset and the audio connection is initiated by the computer. If I
remember tinkering with this stuff, bluez would need to initiate the
control connection in this case.

hcidump -X -V shows messages going across when I tap avrcp buttons...


> ACL data: handle 42 flags 0x02 dlen 12
    L2CAP(d): cid 0x0043 len 8 [psm 0]
      0000: a0 11 0e 00 48 7c 4b 00                           ....H|K.
< ACL data: handle 42 flags 0x02 dlen 12
    L2CAP(d): cid 0x0053 len 8 [psm 0]
      0000: a2 11 0e 09 48 7c 4b 00                           ....H|K.
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 42 packets 1
> HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 42 mode 0x00 interval 0
    Mode: Active
> ACL data: handle 42 flags 0x02 dlen 12
    L2CAP(d): cid 0x0043 len 8 [psm 0]
      0000: b0 11 0e 00 48 7c cb 00                           ....H|..
< ACL data: handle 42 flags 0x02 dlen 12
    L2CAP(d): cid 0x0053 len 8 [psm 0]
      0000: b2 11 0e 09 48 7c cb 00                           ....H|..
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 42 packets 1
> HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 42 mode 0x02 interval 200
    Mode: Sniff

-- 
Brad Midgley

^ permalink raw reply

* Sim Access profile server implementation
From: suraj @ 2010-09-28  7:05 UTC (permalink / raw)
  To: linux-bluetooth@vger.kernel.org; +Cc: Jothikumar Mothilal

Hi,

Please find the Git tree for the Sim access profile server role
implementation I have been working on at

git://gitorious.org/sap-server/sap-server.git

Not sure it could be directly used with Bluez. Nevertheless, it has the
parser implementation of Bluetooth SAP packet. Someone could possibly
reuse it in their implementation.

Regards
Suraj


^ permalink raw reply

* Re: Support for Device ID profile
From: Rahul Ruikar @ 2010-09-28  5:39 UTC (permalink / raw)
  To: steven bluez, Jose Antonio Santos Cadenas, Luiz Augusto von Dentz,
	linux-bluetooth
In-Reply-To: <AANLkTimVPFppVjbdmJSmcjeeNn7jwRf+uvLVC67xPjav@mail.gmail.com>

Hi All,

Could you please tell me some pointers in code/document where I can
know about various profiles
we support here or about profiles for which support is not added yet.

I would like to contribute towards adding support of profiles.
http://www.bluetooth.com/English/Technology/Works/Pages/Profiles_Overview.aspx

Thanks
 Rahul Ruikar





On 28 September 2010 10:23, steven bluez <steven.bluez@gmail.com> wrote:
> Hi Jose,
>> Hi,
>>
>> 2010/9/24 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
>>> Hi Steven,
>>>
>>> Yes, you can use DeviceID on main.conf to add that, but as you see it
>>> is pretty limited so we are planning to have a better support for
>>> this, perhaps extend adapter driver interface where you can write a
>>> plugin to fill this information.
>>
>
> I have started to work on it thats why I cleared up my doubts.
>> Is anyone working on this plugin now. I'd like to work on it if nobody
>> is working yet.
>>
>> Regards.
>>
>>>
>>> Regards,
>>>
>>> On Fri, Sep 24, 2010 at 11:54 AM, steven bluez <steven.bluez@gmail.com> wrote:
>>>> Hi all,
>>>>       Is there any support for Device ID Profile in Bluez 4.XX? versions ?\
>>>>
>>>> Regards,
>>>> Steven
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>>
>>>
>>> --
>>> Luiz Augusto von Dentz
>>> Computer Engineer
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply

* Re: Support for Device ID profile
From: steven bluez @ 2010-09-28  4:53 UTC (permalink / raw)
  To: Jose Antonio Santos Cadenas; +Cc: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <AANLkTi==cFMZfr-achvT=5HNpR5p_36mC7=ybHTYcQc=@mail.gmail.com>

Hi Jose,
> Hi,
>
> 2010/9/24 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
>> Hi Steven,
>>
>> Yes, you can use DeviceID on main.conf to add that, but as you see it
>> is pretty limited so we are planning to have a better support for
>> this, perhaps extend adapter driver interface where you can write a
>> plugin to fill this information.
>

I have started to work on it thats why I cleared up my doubts.
> Is anyone working on this plugin now. I'd like to work on it if nobody
> is working yet.
>
> Regards.
>
>>
>> Regards,
>>
>> On Fri, Sep 24, 2010 at 11:54 AM, steven bluez <steven.bluez@gmail.com> wrote:
>>> Hi all,
>>>       Is there any support for Device ID Profile in Bluez 4.XX? versions ?\
>>>
>>> Regards,
>>> Steven
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>>
>> --
>> Luiz Augusto von Dentz
>> Computer Engineer
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

^ permalink raw reply

* Re: pull-request: bluetooth-2.6 2010-09-27
From: David Miller @ 2010-09-28  3:00 UTC (permalink / raw)
  To: padovan; +Cc: linville, marcel, linux-bluetooth, netdev
In-Reply-To: <20100928023035.GA3033@vigoh>

From: "Gustavo F. Padovan" <padovan@profusion.mobi>
Date: Mon, 27 Sep 2010 23:30:35 -0300

> And a fix for a deadlock issue between the sk_sndbuf and the backlog
> queue in ERTM. The rest are also needed bug fixes.

This fix is still under discussion.

That change effects quite a few code paths.  And when I looked
at them, I was not at all convinced that dropping the socket
lock like that is safe.

Are you sure there are no pieces of socket or socket related state
that might change under us while we drop that lock, which would thus
make the operation suddenly invalid or cause a state corruption or
crash?

You really need to audit this.

^ permalink raw reply

* pull-request: bluetooth-2.6 2010-09-27
From: Gustavo F. Padovan @ 2010-09-28  2:30 UTC (permalink / raw)
  To: davem; +Cc: linville, marcel, linux-bluetooth, netdev

Hi David,

These are the Bluetooth fixes for 2.6.36, you are used to see Marcel doing this
job, but he has been busy lately so I'm taking the job of the pull request this
time. Since we are a bit late on the pull request I'm skipping the
wireless-2.6 step, tell me if you (including John here) disagree.

In this patch set we have two fixes for regressions in L2CAP due to ERTM code
we added in L2CAP for 2.6.36, a bugfix in the L2CAP Streaming Mode that was
making the kernel crash. And a fix for a deadlock issue between the sk_sndbuf
and the backlog queue in ERTM. The rest are also needed bug fixes.

Please tell me any problem you have pulling this.

PS: Considering that these patches do not go immediately to net-next how do I
run the Bluetooth pull request to net-next? Currently my -next tree is rebased
on net-next but before the bluetooth-next patches I put the bluetooth patches
I have in my bluetooth-2.6 tree, i.e., when making the pull request I have to be
sure that the -next patches will be on top of the patches I'm submitting now
for 2.6.36. Any help on that is welcome. :)

Regards,


---

The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c:

  Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master

Andrei Emeltchenko (1):
      Bluetooth: fix MTU L2CAP configuration parameter

Gustavo F. Padovan (4):
      Bluetooth: Simplify L2CAP Streaming mode sending
      Bluetooth: Fix inconsistent lock state with RFCOMM
      Revert "Bluetooth: Don't accept ConfigReq if we aren't in the BT_CONFIG state"
      Bluetooth: Fix deadlock in the ERTM logic

Mat Martineau (1):
      Bluetooth: Only enable L2CAP FCS for ERTM or streaming

 include/net/bluetooth/bluetooth.h |   11 +++++++
 net/bluetooth/l2cap.c             |   57 +++++++++++++++---------------------
 net/bluetooth/rfcomm/sock.c       |    4 ++
 3 files changed, 39 insertions(+), 33 deletions(-)

-- 
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi

^ permalink raw reply

* Re: [PATCH 1/2] Bluetooth: set sk_sndbuf and sk_rcvbuf properly in ERTM
From: Mat Martineau @ 2010-09-27 21:22 UTC (permalink / raw)
  To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1285618609-11499-1-git-send-email-padovan@profusion.mobi>


Gustavo -

On Mon, 27 Sep 2010, Gustavo F. Padovan wrote:

> Setting both this value to MPS * TxWin * 1.2 guarantees that we are
> reserving space to fit the whole txwindow in the memory, and that
> sendmsg() will block when the transmission window is full avoid
> overloading the system memory.
> I don't have a strong reason about the 1.2 constant in the account, we
> can do another tests in the future and change that value.
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> net/bluetooth/l2cap_core.c |   10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 44aa034..1e2ab05 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -3129,9 +3129,17 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hdr
> 		l2cap_pi(sk)->next_tx_seq = 0;
> 		l2cap_pi(sk)->expected_tx_seq = 0;
> 		__skb_queue_head_init(TX_QUEUE(sk));
> -		if (l2cap_pi(sk)->mode ==  L2CAP_MODE_ERTM)
> +		if (l2cap_pi(sk)->mode ==  L2CAP_MODE_ERTM) {
> 			l2cap_ertm_init(sk);
>
> +			sk->sk_sndbuf = (l2cap_pi(sk)->remote_tx_win * 1.2 *
> +						(sizeof(struct l2cap_pinfo) +
> +						l2cap_pi(sk)->mps));
> +			sk->sk_rcvbuf = (l2cap_pi(sk)->tx_win * 1.2 *
> +						(sizeof(struct l2cap_pinfo) +
> +						l2cap_pi(sk)->remote_mps));
> +		}
> +
> 		l2cap_chan_ready(sk);
> 	}
>
> -- 
> 1.7.3

I think sizeof(struct sk_buff) would be better than
sizeof(struct l2cap_pinfo), since these limits apply to data buffers, 
not per-socket overhead.

The 1.2 constant would need to be increased if we allow ERTM MPS
bigger than the HCI MTU, since there would be multiple sk_buffs per 
PDU.  However, the calculation could be updated when those MPS changes 
are made.

It would also help to enforce some limits:
SOCK_MIN_SNDBUF < sk->sk_sndbuf < sysctl_wmem_max
SOCK_MIN_RCVBUF < sk->sk_rcvbuf < sysctl_rmem_max


Regards,

--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum


^ permalink raw reply

* Re: [PATCH 2/2 v3] bluetooth: Add support Bluetooth controller of MacbookPro 7,1
From: Gustavo F. Padovan @ 2010-09-27 21:18 UTC (permalink / raw)
  To: Nobuhiro Iwamatsu; +Cc: linux-bluetooth
In-Reply-To: <1282289047-21444-2-git-send-email-iwamatsu@nigauri.org>

Hi Nobuhiro,

* Nobuhiro Iwamatsu <iwamatsu@nigauri.org> [2010-08-20 16:24:07 +0900]:

> Bluetooth controller of MacbookPro 7,1 does not work.
> Because Device Class of these controllers was set 255 (Vendor Sepecific Class).
> 
> T:  Bus=04 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
> D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=05ac ProdID=8213 Rev=01.86
> S:  Manufacturer=Apple Inc.
> S:  Product=Bluetooth USB Host Controller
> S:  SerialNumber=5C5948C81B99
> C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
> I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
> 
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
>  drivers/bluetooth/btusb.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)

Both patches have been applied to my bluetooth-next-2.6 tree.

-- 
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi

^ permalink raw reply

* Re: [PATCH v3 2/2] Bluetooth: Implement LE Set Scan Enable cmd
From: Gustavo F. Padovan @ 2010-09-27 20:51 UTC (permalink / raw)
  To: Anderson Briglia; +Cc: linux-bluetooth
In-Reply-To: <1284384122-8393-2-git-send-email-anderson.briglia@openbossa.org>

Hi Anderson,

* Anderson Briglia <anderson.briglia@openbossa.org> [2010-09-13 09:22:02 -0400]:

> This patch implements LE Set Scan Enable command for dual
> mode and Low Energy hci controllers. It also adds new HCI flags
> in order to indicate the LE Scanning state for userland applications
> and kernel itself.
> 
> Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
> ---
>  include/net/bluetooth/hci.h |    5 +++++
>  net/bluetooth/hci_event.c   |   27 +++++++++++++++++++++++++++
>  2 files changed, 32 insertions(+), 0 deletions(-)

Both patches have been applied to my bluetooth-next-2.6 tree.

-- 
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi

^ permalink raw reply

* Re: [PATCH] Bluetooth: Don't clear the blacklist when closing the HCI device
From: Gustavo F. Padovan @ 2010-09-27 20:49 UTC (permalink / raw)
  To: Ville Tervo
  Cc: ext johan.hedberg@gmail.com, linux-bluetooth@vger.kernel.org,
	Hedberg Johan (Nokia-MS/Helsinki)
In-Reply-To: <20100915094909.GB14330@null>

Hi Johan,

* Ville Tervo <ville.tervo@nokia.com> [2010-09-15 12:49:09 +0300]:

> On Thu, Sep 09, 2010 at 09:32:39AM +0200, ext johan.hedberg@gmail.com wrote:
> > From: Johan Hedberg <johan.hedberg@nokia.com>
> > 
> > Clearing the blacklist in hci_dev_do_close() would mean that user space
> > needs to do extra work to re-block devices after a DEVDOWN-DEVUP cycle.
> > This patch removes the clearing of the blacklist in this case and
> > thereby saves user space from the extra work.
> > 
> > Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
> 
> Acked-by: Ville Tervo <ville.tervo@nokia.com>

Patch has been applied to my bluetooth-next-2.6 tree to later merge in 
wireless-next-2.6

-- 
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi

^ permalink raw reply

* Re: [PATCH] Bluetooth: remove extra newline from debug output
From: Gustavo F. Padovan @ 2010-09-27 20:45 UTC (permalink / raw)
  To: Ville Tervo; +Cc: ext Emeltchenko Andrei, linux-bluetooth@vger.kernel.org
In-Reply-To: <20100915102952.GD14330@null>

Hi Andrei,

* Ville Tervo <ville.tervo@nokia.com> [2010-09-15 13:29:53 +0300]:

> Hi Andrei,
> 
> On Wed, Sep 08, 2010 at 03:26:53PM +0200, ext Emeltchenko Andrei wrote:
> > From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> > 
> > 
> > Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> 
> Acked-by: Ville Tervo <ville.tervo@nokia.com>

Patch has been applied to my bluetooth-next-2.6 tree to later merge in
wireless-next-2.6

-- 
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox