* [PATCH] Fix multiple phone number problem in pull vcard
From: Radoslaw Jablonski @ 2010-08-10 7:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
This fixes problem with pull vcard when contact has more than one home or
work number defined in tracker - more than one VCARD was generated in
response for pull vcard request. This was caused by nature of the data
retrieved from tracker - contact with multiple numbers set was returned as
many entries with identical id. Previously VCARDs was generated on the fly
- now added contact-data caching and checking for contact id. VCARD is now
generated when all responses of tracker were processed - and only one vcard
is returned for one contact entry.
---
plugins/phonebook-tracker.c | 130 ++++++++++++++++++++++++++++++++++++-------
1 files changed, 109 insertions(+), 21 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index f2b9649..3a90d30 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -43,6 +43,9 @@
#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 19
+#define PHONE_ID_HOME 0
+#define PHONE_ID_WORK 3
#define CONTACTS_QUERY_ALL \
"SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
@@ -275,13 +278,18 @@ struct pending_reply {
int num_fields;
};
+struct contact_data {
+ char *id;
+ struct phonebook_contact *contact;
+};
+
struct phonebook_data {
- GString *vcards;
phonebook_cb cb;
void *user_data;
int index;
gboolean vcardentry;
const struct apparam_field *params;
+ GSList *contacts;
};
struct cache_data {
@@ -545,20 +553,103 @@ static void set_call_type(struct phonebook_contact *contact,
contact->datetime = iso8601_utc_to_localtime(datetime);
}
+static struct phonebook_contact *find_contact(GSList *contacts, const char *id)
+{
+ GSList *l;
+ struct contact_data *c_data;
+
+ for (l = contacts; l; l = l->next) {
+ c_data = l->data;
+ if (g_strcmp0(c_data->id, id) == 0)
+ return c_data->contact;
+ }
+
+ return NULL;
+}
+
+static struct phonebook_number *find_phone(GSList *numbers, const char *phone,
+ int type)
+{
+ GSList *l;
+ struct phonebook_number *pb_num;
+
+ for (l = numbers; l; l = l->next) {
+ pb_num = l->data;
+ /* Returning phonebook number if phone values and type values
+ * are equal */
+ if (g_strcmp0(pb_num->tel, phone) == 0 && pb_num->type == type)
+ return pb_num;
+ }
+
+ return NULL;
+}
+
+static void add_phone_number(struct phonebook_contact *contact,
+ const char *phone, int type)
+{
+ struct phonebook_number *number;
+
+ if (phone == NULL || strlen(phone) == 0)
+ return;
+
+ /* Not adding number if there is already added with the same value */
+ if (find_phone(contact->numbers, phone, type))
+ return;
+
+ number = g_new0(struct phonebook_number, 1);
+ number->tel = g_strdup(phone);
+ number->type = type;
+
+ contact->numbers = g_slist_append(contact->numbers, number);
+}
+
+static GString *gen_vcards(GSList *contacts,
+ const struct apparam_field *params)
+{
+ GSList *l;
+ GString *vcards;
+ struct contact_data *c_data;
+
+ vcards = g_string_new(NULL);
+
+ /* Generating VCARD string from contacts and freeing used contacts */
+ for (l = contacts; l; l = l->next) {
+ c_data = l->data;
+ phonebook_add_contact(vcards, c_data->contact,
+ params->filter, params->format);
+
+ g_free(c_data->id);
+ phonebook_contact_free(c_data->contact);
+ }
+
+ return vcards;
+}
+
static void pull_contacts(char **reply, int num_fields, void *user_data)
{
struct phonebook_data *data = user_data;
const struct apparam_field *params = data->params;
struct phonebook_contact *contact;
- struct phonebook_number *number;
- GString *vcards = data->vcards;
+ struct contact_data *contact_data;
+ GString *vcards;
int last_index, i;
+ gboolean cdata_present = FALSE;
DBG("reply %p", reply);
if (reply == NULL)
goto done;
+ /* Trying to find contact in recently added contacts. It is needed for
+ * contacts that have more than one telephone number filled */
+ contact = find_contact(data->contacts, reply[CONTACTS_ID_COL]);
+
+ /* If contact is already created then adding only new phone numbers */
+ if (contact) {
+ cdata_present = TRUE;
+ goto add_numbers;
+ }
+
/* We are doing a PullvCardEntry, no need for those checks */
if (data->vcardentry)
goto add_entry;
@@ -603,33 +694,32 @@ add_entry:
set_call_type(contact, reply[16], reply[17], reply[18]);
- number = g_new0(struct phonebook_number, 1);
- number->tel = g_strdup(reply[0]);
- number->type = 0; /* HOME */
-
- contact->numbers = g_slist_append(contact->numbers, number);
-
- /* Has WORK Phonenumber */
- if (strlen(reply[8])) {
- number = g_new0(struct phonebook_number, 1);
- number->tel = g_strdup(reply[8]);
- number->type = 3; /* WORK */
-
- contact->numbers = g_slist_append(contact->numbers, number);
- }
+add_numbers:
+ /* Adding phone numbers to contact struct */
+ add_phone_number(contact, reply[0], PHONE_ID_HOME);
+ add_phone_number(contact, reply[8], PHONE_ID_WORK);
DBG("contact %p", contact);
- phonebook_add_contact(vcards, contact, params->filter, params->format);
- phonebook_contact_free(contact);
+ /* Adding contacts data to wrapper struct - this data will be used to
+ * generate vcard list */
+ if (!cdata_present) {
+ contact_data = g_new0(struct contact_data, 1);
+ contact_data->contact = contact;
+ contact_data->id = g_strdup(reply[CONTACTS_ID_COL]);
+ data->contacts = g_slist_append(data->contacts, contact_data);
+ }
return;
done:
+ vcards = gen_vcards(data->contacts, params);
+
if (num_fields == 0)
data->cb(vcards->str, vcards->len, data->index, 0,
data->user_data);
+ g_slist_free(data->contacts);
g_string_free(vcards, TRUE);
g_free(data);
}
@@ -775,7 +865,6 @@ int phonebook_pull(const char *name, const struct apparam_field *params,
return -ENOENT;
data = g_new0(struct phonebook_data, 1);
- data->vcards = g_string_new(NULL);
data->params = params;
data->user_data = user_data;
data->cb = cb;
@@ -794,7 +883,6 @@ int phonebook_get_entry(const char *folder, const char *id,
DBG("folder %s id %s", folder, id);
data = g_new0(struct phonebook_data, 1);
- data->vcards = g_string_new(NULL);
data->user_data = user_data;
data->params = params;
data->cb = cb;
--
1.7.0.4
^ permalink raw reply related
* Re: RFC: QuIC's AMP + eL2CAP Technical Plans
From: Tim Monahan-Mitchell @ 2010-08-09 22:21 UTC (permalink / raw)
To: David Vrabel; +Cc: tmonahan, Marcel Holtmann, linux-bluetooth
In-Reply-To: <4C607D4C.8090407@csr.com>
Hi, David.
> David Vrabel wrote:
>> Tim Monahan-Mitchell wrote:
>>>
>>> If the HCI_80211 symbol in hci.h is changed instead to HCI_AMP, where
>>> should the 0x01 value for '802.11 AMP Controller' (listed in
>>> Bluetooth.org's Assigned Number listing for Controller_Type) go?e
>>
>> I don't think it needs to go anywhere, the actual values aren't
>> important from the point of view of the AMP manager.
>
> I may have misunderstood your question. There will need to be an
> additional "controller_type" field which will get filled in when the
> local amp info is read from the controller.
>
> There will also need to be a table somewhere mapping controller types to
> dedicated amp link key length and KeyID. The will be filled in from the
> assigned numbers and will be a very short table one 1 entry for now.
>
> I do not think we need #define for the various AMP controller types.
I would think such a set of #defines are needed, so that everyone is on
the same page?
Put another way, if one device has an AMP of type 802.11, and a remote has
an AMP of type HCI_UWB, it would seem the AMP Manager needs to know not to
try to converse via AMP with that peer, no?
Also have a look at the Core Spec, under 'READ LOCAL AMP INFO COMMAND'.
The 'Controller_Type' list (of which there is only 802.11 now) will
grow...
Controller Type appears elsewhere in the A2MP protocol...
Sorry if I'm not following you completely.
--
Regards,
Tim Monahan-Mitchell
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: RFC: QuIC's AMP + eL2CAP Technical Plans
From: David Vrabel @ 2010-08-09 22:12 UTC (permalink / raw)
To: tmonahan; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <4C607B43.2050207@csr.com>
David Vrabel wrote:
> Tim Monahan-Mitchell wrote:
>>
>> If the HCI_80211 symbol in hci.h is changed instead to HCI_AMP, where
>> should the 0x01 value for '802.11 AMP Controller' (listed in
>> Bluetooth.org's Assigned Number listing for Controller_Type) go?e
>
> I don't think it needs to go anywhere, the actual values aren't
> important from the point of view of the AMP manager.
I may have misunderstood your question. There will need to be an
additional "controller_type" field which will get filled in when the
local amp info is read from the controller.
There will also need to be a table somewhere mapping controller types to
dedicated amp link key length and KeyID. The will be filled in from the
assigned numbers and will be a very short table one 1 entry for now.
I do not think we need #define for the various AMP controller types.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply
* Re: RFC: QuIC's AMP + eL2CAP Technical Plans
From: David Vrabel @ 2010-08-09 22:03 UTC (permalink / raw)
To: tmonahan; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <4fed618ae82fc803133cc742bbd2eeb6.squirrel@www.codeaurora.org>
Tim Monahan-Mitchell wrote:
>
> If the HCI_80211 symbol in hci.h is changed instead to HCI_AMP, where
> should the 0x01 value for '802.11 AMP Controller' (listed in
> Bluetooth.org's Assigned Number listing for Controller_Type) go?e
I don't think it needs to go anywhere, the actual values aren't
important from the point of view of the AMP manager.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply
* Re: [PATCH 2/2] Use HCI device type to gate BR/EDR-specific HCI commands
From: Johan Hedberg @ 2010-08-09 21:59 UTC (permalink / raw)
To: David Scherba; +Cc: linux-bluetooth, marcel, rshaffer
In-Reply-To: <1281388059-15945-3-git-send-email-dscherba@codeaurora.org>
Hi David,
On Mon, Aug 09, 2010, David Scherba wrote:
> +static inline int is_bredr_hci_device_type(uint8_t type)
Could you just call this ignore_device() which combines the AMP and RAW
checks.
> +{
> + return (type >> 4) == HCI_BREDR;
> +}
Looks like the indentation is wrong inside the function (two spaces
instead of a tab).
> - if (hci_test_bit(HCI_RAW, &di.flags))
> + if (!is_bredr_hci_device_type(di.type) ||
> + hci_test_bit(HCI_RAW, &di.flags))
No spaces+tabs mixed indentation please. The second line should be
indented by at least two tabs more than the line above it (as many tabs
as you can as long as the line doesn't go beyond 79 characters). OTOH,
the second line goes away completely if you do the ignore_device
simplification as proposed above.
> - if (!hci_test_bit(HCI_RAW, &di.flags))
> + if (is_bredr_hci_device_type(di.type) &&
> + !hci_test_bit(HCI_RAW, &di.flags))
Same here.
> - if (hci_test_bit(HCI_RAW, &di.flags)) {
> + if (!is_bredr_hci_device_type(di.type) ||
> + hci_test_bit(HCI_RAW, &di.flags)) {
And here.
> - if (hci_test_bit(HCI_RAW, &di->flags))
> + if (!is_bredr_hci_device_type(di->type) ||
> + hci_test_bit(HCI_RAW, &di->flags))
And here.
> - if (hci_test_bit(HCI_RAW, &di->flags))
> + if (!is_bredr_hci_device_type(di->type) ||
> + hci_test_bit(HCI_RAW, &di->flags))
And here.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Remove non-functional hci_devinfo calls in init_device()
From: Johan Hedberg @ 2010-08-09 21:51 UTC (permalink / raw)
To: David Scherba; +Cc: linux-bluetooth, marcel, rshaffer
In-Reply-To: <1281388059-15945-2-git-send-email-dscherba@codeaurora.org>
Hi David,
On Mon, Aug 09, 2010, David Scherba wrote:
> ---
> plugins/hciops.c | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/plugins/hciops.c b/plugins/hciops.c
> index 5775cf1..b38c056 100644
> --- a/plugins/hciops.c
> +++ b/plugins/hciops.c
> @@ -175,12 +175,6 @@ static void init_device(int index)
> goto fail;
> }
>
> - if (hci_devinfo(index, &di) < 0)
> - goto fail;
> -
> - if (hci_test_bit(HCI_RAW, &di.flags))
> - goto done;
> -
> done:
> hci_close_dev(dd);
> exit(0);
Nice catch, but that's not quite enough:
plugins/hciops.c: In function ‘init_device’:
plugins/hciops.c:178: error: label ‘done’ defined but not used
plugins/hciops.c:125: error: unused variable ‘di’
Always check that your patch compiles cleanly with ./bootstrap-configure
before submitting upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Support SDIO devices that are AMP controllers
From: Marcel Holtmann @ 2010-08-09 21:44 UTC (permalink / raw)
To: David Vrabel; +Cc: linux-bluetooth
In-Reply-To: <4C604FAD.40801@csr.com>
Hi David,
> Signed-off-by: David Vrabel <david.vrabel@csr.com>
> ---
> drivers/bluetooth/btsdio.c | 4 ++++
> include/linux/mmc/sdio_ids.h | 1 +
> 2 files changed, 5 insertions(+), 0 deletions(-)
since your patch didn't apply cleanly, I re-wrote a little ;)
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: btmrvl: devices are either BR/EDR or AMPs
From: David Vrabel @ 2010-08-09 21:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
[-- Attachment #2: 0001-Bluetooth-btmrvl-devices-are-either-BR-EDR-or-AMPs.patch --]
[-- Type: text/x-diff, Size: 981 bytes --]
>From 5d16a92e61d8457077d0235d6b7006b824ff6891 Mon Sep 17 00:00:00 2001
From: David Vrabel <dv02@dv02-laptop.(none)>
Date: Mon, 9 Aug 2010 22:39:43 +0100
Subject: [PATCH] Bluetooth: btmrvl: devices are either BR/EDR or AMPs
Signed-off-by: David Vrabel <david.vrabel@csr.com>
---
drivers/bluetooth/btmrvl_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 0d32ec8..548d1d9 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -117,8 +117,8 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
(event->data[2] == MODULE_ALREADY_UP)) ?
"Bring-up succeed" : "Bring-up failed");
- if (event->length > 3)
- priv->btmrvl_dev.dev_type = event->data[3];
+ if (event->length > 3 && event->data[3])
+ priv->btmrvl_dev.dev_type = HCI_AMP;
else
priv->btmrvl_dev.dev_type = HCI_BREDR;
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] Bluetooth: HCI devices are either BR/EDR or AMP radios
From: Marcel Holtmann @ 2010-08-09 21:39 UTC (permalink / raw)
To: David Vrabel; +Cc: linux-bluetooth
In-Reply-To: <4C604F37.4020706@csr.com>
Hi David,
> HCI transport drivers may not know what type of radio an AMP device has
> so only say whether they're BR/EDR or AMP devices.
>
> Signed-off-by: David Vrabel <david.vrabel@csr.com>
> ---
> include/net/bluetooth/hci.h | 2 +-
> net/bluetooth/hci_sysfs.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
a little bit different version that also fixes the Marvell driver has
been applied to my tree. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: RFC: QuIC's AMP + eL2CAP Technical Plans
From: Tim Monahan-Mitchell @ 2010-08-09 21:30 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: David Vrabel, tmonahan, linux-bluetooth
In-Reply-To: <1268072572.3712.24.camel@localhost.localdomain>
Hi David and Marcel,
I added on to this thread in regards to today's patch of "Bluetooth: HCI
devices are either BR/EDR or AMP radios" (09-Aug-2010).
>> > The block-based flow control is a missing piece, but the AMP type
>> > extension has been merged upstream. We can create HCI_BREDR and
>> > HCI_80211 controllers now. The AMP controllers are for now forced to
>> be
>> > raw devices, but that can be changed easily once we have the
>> controller
>> > init for AMP up and ready.
>>
>> Why HCI_80211 and not HCI_AMP? The stack shouldn't care what the AMP's
>> radio actually is and with some devices (e.g., standard SDIO ones) it's
>> not even possible to tell what the radio is.
>
> we will be adding a HCI_UWB once that specification gets ratified. And
> the controller type is an official piece of information inside the AMP
> manager. That part needs to know which type of AMP it is. Also the
> driver actually should know what type of AMP it is.
>
> I see your point that for fully generic HCI transports they might not
> know the type upfront and we need to handle that. We will cross that
> bridge when we come to it. Right now we just got started.
>
> Regards
>
> Marcel
If the HCI_80211 symbol in hci.h is changed instead to HCI_AMP, where
should the 0x01 value for '802.11 AMP Controller' (listed in
Bluetooth.org's Assigned Number listing for Controller_Type) go?
Thanks,
Tim Monahan-Mitchell
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 2/2] Use HCI device type to gate BR/EDR-specific HCI commands
From: David Scherba @ 2010-08-09 21:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, marcel, rshaffer, David Scherba
In-Reply-To: <1281388059-15945-1-git-send-email-dscherba@codeaurora.org>
Use the hci_dev_info structure member 'type' to classify whether a HCI device
is BR/EDR, or not. If not, gate BR/EDR-specific HCI commands.
---
lib/hci_lib.h | 5 +++++
plugins/hciops.c | 23 +++++++++++++++--------
src/adapter.c | 3 ++-
src/security.c | 6 ++++--
4 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index b63a2a4..c0786ab 100644
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -169,6 +169,11 @@ static inline int hci_test_bit(int nr, void *addr)
return *((uint32_t *) addr + (nr >> 5)) & (1 << (nr & 31));
}
+static inline int is_bredr_hci_device_type(uint8_t type)
+{
+ return (type >> 4) == HCI_BREDR;
+}
+
/* HCI filter tools */
static inline void hci_filter_clear(struct hci_filter *f)
{
diff --git a/plugins/hciops.c b/plugins/hciops.c
index b38c056..705e9dd 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -85,7 +85,8 @@ static void device_devup_setup(int index)
if (hci_devinfo(index, &di) < 0)
return;
- if (hci_test_bit(HCI_RAW, &di.flags))
+ if (!is_bredr_hci_device_type(di.type) ||
+ hci_test_bit(HCI_RAW, &di.flags))
return;
dd = hci_open_dev(index);
@@ -160,12 +161,17 @@ static void init_device(int index)
index, strerror(err), err);
}
- /* Set link policy */
- dr.dev_opt = main_opts.link_policy;
- if (ioctl(dd, HCISETLINKPOL, (unsigned long) &dr) < 0 &&
- errno != ENETDOWN) {
- error("Can't set link policy on hci%d: %s (%d)",
- index, strerror(errno), errno);
+ /* Set link policy for BR/EDR HCI devices */
+ if (hci_devinfo(index, &di) < 0)
+ goto fail;
+
+ if (is_bredr_hci_device_type(di.type)) {
+ dr.dev_opt = main_opts.link_policy;
+ if (ioctl(dd, HCISETLINKPOL, (unsigned long) &dr) < 0 &&
+ errno != ENETDOWN) {
+ error("Can't set link policy on hci%d: %s (%d)",
+ index, strerror(errno), errno);
+ }
}
/* Start HCI device */
@@ -198,7 +204,8 @@ static void device_devreg_setup(int index)
devup = hci_test_bit(HCI_UP, &di.flags);
- if (!hci_test_bit(HCI_RAW, &di.flags))
+ if (is_bredr_hci_device_type(di.type) &&
+ !hci_test_bit(HCI_RAW, &di.flags))
manager_register_adapter(index, devup);
}
diff --git a/src/adapter.c b/src/adapter.c
index 7d0e34d..acc1068 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2314,7 +2314,8 @@ int adapter_start(struct btd_adapter *adapter)
if (hci_devinfo(adapter->dev_id, &di) < 0)
return -errno;
- if (hci_test_bit(HCI_RAW, &di.flags)) {
+ if (!is_bredr_hci_device_type(di.type) ||
+ hci_test_bit(HCI_RAW, &di.flags)) {
dev->ignore = 1;
return -1;
}
diff --git a/src/security.c b/src/security.c
index ca394e1..6d07d86 100644
--- a/src/security.c
+++ b/src/security.c
@@ -999,7 +999,8 @@ static gboolean io_security_event(GIOChannel *chan, GIOCondition cond,
ioctl(dev, HCIGETDEVINFO, (void *) di);
- if (hci_test_bit(HCI_RAW, &di->flags))
+ if (!is_bredr_hci_device_type(di->type) ||
+ hci_test_bit(HCI_RAW, &di->flags))
return TRUE;
switch (eh->evt) {
@@ -1185,7 +1186,8 @@ void start_security_manager(int hdev)
io_data[hdev].channel = chan;
io_data[hdev].pin_length = -1;
- if (hci_test_bit(HCI_RAW, &di->flags))
+ if (!is_bredr_hci_device_type(di->type) ||
+ hci_test_bit(HCI_RAW, &di->flags))
return;
bacpy(&cp.bdaddr, BDADDR_ANY);
--
1.7.0
--
David Scherba
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 1/2] Remove non-functional hci_devinfo calls in init_device()
From: David Scherba @ 2010-08-09 21:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, marcel, rshaffer, David Scherba
In-Reply-To: <1281388059-15945-1-git-send-email-dscherba@codeaurora.org>
---
plugins/hciops.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/plugins/hciops.c b/plugins/hciops.c
index 5775cf1..b38c056 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -175,12 +175,6 @@ static void init_device(int index)
goto fail;
}
- if (hci_devinfo(index, &di) < 0)
- goto fail;
-
- if (hci_test_bit(HCI_RAW, &di.flags))
- goto done;
-
done:
hci_close_dev(dd);
exit(0);
--
1.7.0
--
David Scherba
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 0/2] Use HCI device type to determine suitability of HCI commands
From: David Scherba @ 2010-08-09 21:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, marcel, rshaffer
BlueZ assumes that HCI devices are either BR/EDR radios, or "RAW" (via
HCI_RAW). At present, alternate radios are handled as RAW (reference
Marcel's 943da25d9 kernel commit). More subtlety in BlueZ is useful as
AMP support is enhanced.
These patches remove the need to treat non-BR/EDR HCI devices as "RAW."
Cheers,
David
--
David Scherba
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] return value checking of e_book_async_get_contacts() was wrong.
From: Johan Hedberg @ 2010-08-09 20:55 UTC (permalink / raw)
To: Marcel Mol; +Cc: linux-bluetooth
In-Reply-To: <201008092047.o79KlQDL015265@joshua.mesa.nl>
Hi Marcel,
On Mon, Aug 09, 2010, Marcel Mol wrote:
> phonebook_create_cache() failed because checking the return value
> e_book_async_get_contacts() was wrong. This would lead to a core dump
> as the data was freed but was still used in the callbacks.
> ---
> plugins/phonebook-ebook.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/plugins/phonebook-ebook.c b/plugins/phonebook-ebook.c
> index 3c24107..1598d5f 100644
> --- a/plugins/phonebook-ebook.c
> +++ b/plugins/phonebook-ebook.c
> @@ -459,7 +459,7 @@ int phonebook_create_cache(const char *name, phonebook_entry_cb entry_cb,
>
> ret = e_book_async_get_contacts(ebook, query, cache_cb, data);
> e_book_query_unref(query);
> - if (ret == FALSE) {
> + if (ret != FALSE) {
> g_free(data);
> return -EFAULT;
> }
Thanks for catching this. The patch is now upstream.
Johan
^ permalink raw reply
* [PATCH] return value checking of e_book_async_get_contacts() was wrong.
From: Marcel Mol @ 2010-08-09 20:43 UTC (permalink / raw)
To: linux-bluetooth
phonebook_create_cache() failed because checking the return value
e_book_async_get_contacts() was wrong. This would lead to a core dump
as the data was freed but was still used in the callbacks.
---
plugins/phonebook-ebook.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-ebook.c b/plugins/phonebook-ebook.c
index 3c24107..1598d5f 100644
--- a/plugins/phonebook-ebook.c
+++ b/plugins/phonebook-ebook.c
@@ -459,7 +459,7 @@ int phonebook_create_cache(const char *name, phonebook_entry_cb entry_cb,
ret = e_book_async_get_contacts(ebook, query, cache_cb, data);
e_book_query_unref(query);
- if (ret == FALSE) {
+ if (ret != FALSE) {
g_free(data);
return -EFAULT;
}
--
1.7.2
^ permalink raw reply related
* Re: Question about BlueZ licenses (LGPL and Apache)
From: Pavan Savoy @ 2010-08-09 19:37 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Madhavi Manchala, linux-bluetooth
In-Reply-To: <AANLkTinUKu+GrAnJvZoZmhcb9=6ZOxhTBZhRv5i5NKBs@mail.gmail.com>
As long as we are updating, can the liba2dp be abstracted out of not
only the sbc encoding part but also the sending over UART part (as in
transport ...)
chips are getting smarter and the sbc codecs are moving to either a
co-processor/dsp or even inside the BT chip itself, so we might have
to send the PCM raw data somewhere else for the dsp to encode to sbc
and send it over the air ...
currently the data (sbc/pcm) and the control (connection
establishment) is too tightly sort of coded in together.. isn't it ?
for something like the above to happen our liba2dp had to be almost
re-written ...
On 8/9/10, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Fri, Aug 6, 2010 at 6:44 PM, Madhavi Manchala
> <madhavi.linux@gmail.com> wrote:
>> Dear All,
>>
>> I am trying to implement a custom voice codec on the android bluetooth
>> platform by linking it, into the A2DP module. I have heard different
>> versions from different people regarding the licenses (like LGPL and
>> Apache License). So, before starting my work, I would like to know if
>> I would be forced to reveal my source code, once I implement my codec
>> on BlueZ stack. Please let me know, so that I can choose my platform,
>> before starting my work.
>
> If you are just implementing a new codec then you might have to link
> to GPL code which basically makes your code GPL too, but we have plans
> to support this over dbus which wouldn't require you to link to any
> GPL, instead you register an endpoint which will be used to configure
> streams.
>
> This code can be found here:
>
> http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
>
> This depend on dbus 1.3.1 and latter which will probably only reach
> upstream once we have a dbus 1.4 release.
>
> --
> 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
* [PATCH] Bluetooth: Support SDIO devices that are AMP controllers
From: David Vrabel @ 2010-08-09 18:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann
Signed-off-by: David Vrabel <david.vrabel@csr.com>
---
drivers/bluetooth/btsdio.c | 4 ++++
include/linux/mmc/sdio_ids.h | 1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index 76e5127..061e0a4 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -46,6 +46,9 @@ static const struct sdio_device_id btsdio_table[] = {
/* Generic Bluetooth Type-B SDIO device */
{ SDIO_DEVICE_CLASS(SDIO_CLASS_BT_B) },
+ /* Generic Bluetooth AMP controller */
+ { SDIO_DEVICE_CLASS(SDIO_CLASS_BT_AMP) },
+
{ } /* Terminating entry */
};
@@ -327,6 +330,7 @@ static int btsdio_probe(struct sdio_func *func,
}
hdev->bus = HCI_SDIO;
+ hdev->dev_type = (id->class == SDIO_CLASS_BT_AMP) ? HCI_AMP : HCI_BREDR;
hdev->driver_data = data;
data->hdev = hdev;
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 33b2ea0..a36ab3b 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -18,6 +18,7 @@
#define SDIO_CLASS_PHS 0x06 /* PHS standard interface */
#define SDIO_CLASS_WLAN 0x07 /* WLAN interface */
#define SDIO_CLASS_ATA 0x08 /* Embedded SDIO-ATA std interface */
+#define SDIO_CLASS_BT_AMP 0x09 /* Type-A Bluetooth AMP interface */
/*
* Vendors and devices. Sort key: vendor first, device next.
--
1.5.4.3
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply related
* [PATCH] Bluetooth: HCI devices are either BR/EDR or AMP radios
From: David Vrabel @ 2010-08-09 18:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann
HCI transport drivers may not know what type of radio an AMP device has
so only say whether they're BR/EDR or AMP devices.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
---
include/net/bluetooth/hci.h | 2 +-
net/bluetooth/hci_sysfs.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index ca2518e..cc14731 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -54,7 +54,7 @@
/* HCI controller types */
#define HCI_BREDR 0x00
-#define HCI_80211 0x01
+#define HCI_AMP 0x01
/* HCI device quirks */
enum {
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index ce44c47..4e9ca9b 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -196,8 +196,8 @@ static inline char *host_typetostr(int type)
switch (type) {
case HCI_BREDR:
return "BR/EDR";
- case HCI_80211:
- return "802.11";
+ case HCI_AMP:
+ return "AMP";
default:
return "UNKNOWN";
}
--
1.5.4.3
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply related
* Re: [PATCH 1/9] Bluetooth: Only enable for L2CAP FCS for ERTM or streaming.
From: Mat Martineau @ 2010-08-09 16:50 UTC (permalink / raw)
To: Gustavo F. Padovan, Marcel Holtmann
Cc: linux-bluetooth, rshaffer, linux-arm-msm
In-Reply-To: <20100809131254.GB3817@vigoh>
On Mon, 9 Aug 2010, Gustavo F. Padovan wrote:
> Hi Marcel,
>
> * Marcel Holtmann <marcel@holtmann.org> [2010-08-08 22:43:00 -0400]:
>
>> Hi Mat,
>>
>>> This fixes a bug which caused the FCS setting to show L2CAP_FCS_CRC16
>>> with L2CAP modes other than ERTM or streaming. At present, this only
>>> affects the FCS value shown with getsockopt() for basic mode.
>>>
>>> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
>>> ---
>>> net/bluetooth/l2cap.c | 16 ++++++++++++----
>>> 1 files changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>>> index 3e3cd9d..bc10be8 100644
>>> --- a/net/bluetooth/l2cap.c
>>> +++ b/net/bluetooth/l2cap.c
>>> @@ -3072,6 +3072,16 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
>>> return 0;
>>> }
>>>
>>> +static inline int l2cap_fcs_needed(struct l2cap_pinfo *pi)
>>> +{
>>> + if (pi->mode != L2CAP_MODE_ERTM && pi->mode != L2CAP_MODE_STREAMING)
>>> + return 0;
>>> +
>>> + /* FCS is enabled if one or both sides request it. */
>>> + return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
>>> + pi->fcs == L2CAP_FCS_CRC16;
>>> +}
>>
>> so I think a switch statement is easier to read:
>>
>> switch (pi->mode) {
>> case L2CAP_MODE_ERTM:
>> case L2CAP_MODE_STREAMING:
>> return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
>> pi->fcs == L2CAP_FCS_CRC16;
>> }
>>
>> return 0;
>>
>>> static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, u16 cmd_len, u8 *data)
>>> {
>>> struct l2cap_conf_req *req = (struct l2cap_conf_req *) data;
>>> @@ -3136,8 +3146,7 @@ static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr
>>> goto unlock;
>>>
>>> if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
>>> - if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
>>> - l2cap_pi(sk)->fcs != L2CAP_FCS_NONE)
>>> + if (l2cap_fcs_needed(l2cap_pi(sk)))
>>> l2cap_pi(sk)->fcs = L2CAP_FCS_CRC16;
>>
>> While this is just fine, I think we might should make this a lot
>> simpler:
>>
>> if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
>> set_default_fcs(pi);
>>
>> ...
>> }
>>
>> With then set_default_fcs() doing all the checks etc. and setting either
>> FCS_NONE or FCS_CRC16.
>>
>> Would this work or do we have to deal with some funny default behavior?
>
> That will work. ;)
Agreed - that's much more readable.
--
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] Fix multiple phone number problem in pull vcard
From: Johan Hedberg @ 2010-08-09 14:01 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1281352651-30943-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Mon, Aug 09, 2010, Radoslaw Jablonski wrote:
> This fixes problem with pull vcard when contact has more than one home or
> work number defined in tracker - more than one VCARD was generated in
> response for pull vcard request. This was caused by nature of the data
> retrieved from tracker - contact with multiple numbers set was returned as
> many entries with identical id. Previously VCARDs was generated on the fly
> - now added contact-data caching and checking for contact id. VCARD is now
> generated when all responses of tracker were processed - and only one vcard
> is returned for one contact entry.
> ---
> plugins/phonebook-tracker.c | 134 ++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 112 insertions(+), 22 deletions(-)
Some coding style issue that need fixing:
> +struct contact_data
> +{
The { shouldn't go on it's own line, i.e. put it in the above line.
> +static struct phonebook_contact *find_contact (GSList *contacts,char *id)
> +{
Remove the space after "find_contact", add a space after ",". Since
you're not modifying id in the function it should probably be const char *
instead of char *.
> + GSList *it;
Usually simple list iterators are called just "l".
> + for(it = contacts; it; it = it->next) {
Space between for and (
> + for(it = numbers; it; it = it->next) {
Same here, and call the list variable "l".
> +static GString * gen_vcards(GSList *contacts,
> + const struct apparam_field *params)
No space between * and gen_vcards.
> + GSList *it;
Again, call it "l".
> + for(it = contacts; it; it = it->next) {
Space between for and (
> + if (!cdata_present) {
> + contact_data = g_new0(struct contact_data, 1);
> + contact_data->contact = contact;
> + contact_data->id = g_strdup(reply[CONTACTS_ID_COL]);
> + data->contacts = g_slist_append(data->contacts, contact_data);
> + }
> return;
Add an empty line before the return
> data = g_new0(struct phonebook_data, 1);
> - data->vcards = g_string_new(NULL);
> data->params = params;
> data->user_data = user_data;
> data->cb = cb;
> + data->contacts = NULL;
Since you used g_new0 setting to NULL seems redundant.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Fix multiple phone numbers problem in vcard-listing
From: Johan Hedberg @ 2010-08-09 13:55 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1281352623-30856-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Mon, Aug 09, 2010, Radoslaw Jablonski wrote:
> This fixes displaying problem in vcard-listing when contact had multiple
> home or work phone set(one contact was displayed more than one time in
> vcard-listing. Now query is changed and additional entries are omitted.
> ---
> plugins/phonebook-tracker.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
> index 41d7fde..f2b9649 100644
> --- a/plugins/phonebook-tracker.c
> +++ b/plugins/phonebook-tracker.c
> @@ -76,7 +76,7 @@
> "?c nco:hasAffiliation ?a . " \
> "?a nco:hasPhoneNumber ?h . " \
> "} " \
> - "}"
> + "} GROUP BY ?c"
>
> #define MISSED_CALLS_QUERY \
> "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
This patch is now upstream. Thanks.
Johan
^ permalink raw reply
* Re: Workaround for buggy BT dongles
From: Marcel Holtmann @ 2010-08-09 13:36 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Bluettooth Linux
In-Reply-To: <AANLkTimt4CN6Oegrnf3Z5mhb0L7QLiiaPdHCSdp=rLTw@mail.gmail.com>
Hi Andrei,
> We have experienced L2CAP disconnections with A-Link BT dongles (lsusb
> shows Broadcom Corp. BCM2046B1 chip).
>
> There is race condition in a controller so that sometimes "L2CAP
> Connect Req" is received after "HCI Encryption Change":
> ...
> 2308 *REF* HCI_EVT
> Simple Pairing Complete
> 2309 0.089720 HCI_EVT
> Link Key Notification
> 2310 0.126607 L2CAP
> Rcvd Connection Request
> 2311 0.126721 L2CAP
> Sent Connection Response
> 2312 0.127278 HCI_EVT
> Encrypt Change
> ...
>
> This is correct behavior since all non-SDP connections shall be
> encrypted for SSP devices.
>
> If we send "L2CAP Connect Request" with a little delay the problem
> disappears (this is of course too hackish way).
>
> Shall we address this problem? I do not see good way of dealing with the chip.
I would prefer to address this problem as follows. Open your window and
through the dongle out that same window ;)
Regards
Marcel
^ permalink raw reply
* Workaround for buggy BT dongles
From: Andrei Emeltchenko @ 2010-08-09 13:21 UTC (permalink / raw)
To: Bluettooth Linux
Hi,
We have experienced L2CAP disconnections with A-Link BT dongles (lsusb
shows Broadcom Corp. BCM2046B1 chip).
There is race condition in a controller so that sometimes "L2CAP
Connect Req" is received after "HCI Encryption Change":
...
2308 *REF* HCI_EVT
Simple Pairing Complete
2309 0.089720 HCI_EVT
Link Key Notification
2310 0.126607 L2CAP
Rcvd Connection Request
2311 0.126721 L2CAP
Sent Connection Response
2312 0.127278 HCI_EVT
Encrypt Change
...
This is correct behavior since all non-SDP connections shall be
encrypted for SSP devices.
If we send "L2CAP Connect Request" with a little delay the problem
disappears (this is of course too hackish way).
Shall we address this problem? I do not see good way of dealing with the chip.
Regards,
Andrei
^ permalink raw reply
* Re: [PATCH 1/9] Bluetooth: Only enable for L2CAP FCS for ERTM or streaming.
From: Gustavo F. Padovan @ 2010-08-09 13:12 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Mat Martineau, linux-bluetooth, rshaffer, linux-arm-msm
In-Reply-To: <1281321780.12579.184.camel@localhost.localdomain>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2010-08-08 22:43:00 -0400]:
> Hi Mat,
>
> > This fixes a bug which caused the FCS setting to show L2CAP_FCS_CRC16
> > with L2CAP modes other than ERTM or streaming. At present, this only
> > affects the FCS value shown with getsockopt() for basic mode.
> >
> > Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> > ---
> > net/bluetooth/l2cap.c | 16 ++++++++++++----
> > 1 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> > index 3e3cd9d..bc10be8 100644
> > --- a/net/bluetooth/l2cap.c
> > +++ b/net/bluetooth/l2cap.c
> > @@ -3072,6 +3072,16 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
> > return 0;
> > }
> >
> > +static inline int l2cap_fcs_needed(struct l2cap_pinfo *pi)
> > +{
> > + if (pi->mode != L2CAP_MODE_ERTM && pi->mode != L2CAP_MODE_STREAMING)
> > + return 0;
> > +
> > + /* FCS is enabled if one or both sides request it. */
> > + return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> > + pi->fcs == L2CAP_FCS_CRC16;
> > +}
>
> so I think a switch statement is easier to read:
>
> switch (pi->mode) {
> case L2CAP_MODE_ERTM:
> case L2CAP_MODE_STREAMING:
> return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> pi->fcs == L2CAP_FCS_CRC16;
> }
>
> return 0;
>
> > static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, u16 cmd_len, u8 *data)
> > {
> > struct l2cap_conf_req *req = (struct l2cap_conf_req *) data;
> > @@ -3136,8 +3146,7 @@ static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr
> > goto unlock;
> >
> > if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
> > - if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> > - l2cap_pi(sk)->fcs != L2CAP_FCS_NONE)
> > + if (l2cap_fcs_needed(l2cap_pi(sk)))
> > l2cap_pi(sk)->fcs = L2CAP_FCS_CRC16;
>
> While this is just fine, I think we might should make this a lot
> simpler:
>
> if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
> set_default_fcs(pi);
>
> ...
> }
>
> With then set_default_fcs() doing all the checks etc. and setting either
> FCS_NONE or FCS_CRC16.
>
> Would this work or do we have to deal with some funny default behavior?
That will work. ;)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH 2/2] Fix multiple phone number problem in pull vcard
From: Radoslaw Jablonski @ 2010-08-09 11:17 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
This fixes problem with pull vcard when contact has more than one home or
work number defined in tracker - more than one VCARD was generated in
response for pull vcard request. This was caused by nature of the data
retrieved from tracker - contact with multiple numbers set was returned as
many entries with identical id. Previously VCARDs was generated on the fly
- now added contact-data caching and checking for contact id. VCARD is now
generated when all responses of tracker were processed - and only one vcard
is returned for one contact entry.
---
plugins/phonebook-tracker.c | 134 ++++++++++++++++++++++++++++++++++++-------
1 files changed, 112 insertions(+), 22 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index f2b9649..1e197d7 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -43,6 +43,9 @@
#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 19
+#define PHONE_ID_HOME 0
+#define PHONE_ID_WORK 3
#define CONTACTS_QUERY_ALL \
"SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
@@ -275,13 +278,19 @@ struct pending_reply {
int num_fields;
};
+struct contact_data
+{
+ char *id;
+ struct phonebook_contact *contact;
+};
+
struct phonebook_data {
- GString *vcards;
phonebook_cb cb;
void *user_data;
int index;
gboolean vcardentry;
const struct apparam_field *params;
+ GSList *contacts;
};
struct cache_data {
@@ -545,20 +554,103 @@ static void set_call_type(struct phonebook_contact *contact,
contact->datetime = iso8601_utc_to_localtime(datetime);
}
+static struct phonebook_contact *find_contact (GSList *contacts,char *id)
+{
+ GSList *it;
+ struct contact_data *c_data;
+
+ for(it = contacts; it; it = it->next) {
+ c_data = it->data;
+ if (g_strcmp0(c_data->id, id) == 0)
+ return c_data->contact;
+ }
+
+ return NULL;
+}
+
+static struct phonebook_number *find_phone(GSList *numbers, char *phone,
+ int type)
+{
+ GSList *it;
+ struct phonebook_number *pb_num;
+
+ for(it = numbers; it; it = it->next) {
+ pb_num = it->data;
+ /* Returning phonebook number if phone values and type values
+ * are equal */
+ if (g_strcmp0(pb_num->tel, phone) == 0 && pb_num->type == type)
+ return pb_num;
+ }
+
+ return NULL;
+}
+
+static void add_phone_number(struct phonebook_contact *contact, char *phone,
+ int type)
+{
+ struct phonebook_number *number;
+
+ if (phone == NULL || strlen(phone) == 0)
+ return;
+
+ /* Not adding number if there is already added with the same value */
+ if (find_phone(contact->numbers, phone, type))
+ return;
+
+ number = g_new0(struct phonebook_number, 1);
+ number->tel = g_strdup(phone);
+ number->type = type;
+
+ contact->numbers = g_slist_append(contact->numbers, number);
+}
+
+static GString * gen_vcards(GSList *contacts,
+ const struct apparam_field *params)
+{
+ GSList *it;
+ GString *vcards;
+ struct contact_data *c_data;
+
+ vcards = g_string_new(NULL);
+
+ /* Generating VCARD string from contacts and freeing used contacts */
+ for(it = contacts; it; it = it->next) {
+ c_data = it->data;
+ phonebook_add_contact(vcards, c_data->contact,
+ params->filter, params->format);
+
+ g_free(c_data->id);
+ phonebook_contact_free(c_data->contact);
+ }
+
+ return vcards;
+}
+
static void pull_contacts(char **reply, int num_fields, void *user_data)
{
struct phonebook_data *data = user_data;
const struct apparam_field *params = data->params;
struct phonebook_contact *contact;
- struct phonebook_number *number;
- GString *vcards = data->vcards;
+ struct contact_data *contact_data;
+ GString *vcards;
int last_index, i;
+ gboolean cdata_present = FALSE;
DBG("reply %p", reply);
if (reply == NULL)
goto done;
+ /* Trying to find contact in recently added contacts. It is needed for
+ * contacts that have more than one telephone number filled */
+ contact = find_contact(data->contacts, reply[CONTACTS_ID_COL]);
+
+ /* If contact is already created then adding only new phone numbers */
+ if (contact) {
+ cdata_present = TRUE;
+ goto add_numbers;
+ }
+
/* We are doing a PullvCardEntry, no need for those checks */
if (data->vcardentry)
goto add_entry;
@@ -603,33 +695,31 @@ add_entry:
set_call_type(contact, reply[16], reply[17], reply[18]);
- number = g_new0(struct phonebook_number, 1);
- number->tel = g_strdup(reply[0]);
- number->type = 0; /* HOME */
-
- contact->numbers = g_slist_append(contact->numbers, number);
-
- /* Has WORK Phonenumber */
- if (strlen(reply[8])) {
- number = g_new0(struct phonebook_number, 1);
- number->tel = g_strdup(reply[8]);
- number->type = 3; /* WORK */
-
- contact->numbers = g_slist_append(contact->numbers, number);
- }
+add_numbers:
+ /* Adding phone numbers to contact struct */
+ add_phone_number(contact, reply[0], PHONE_ID_HOME);
+ add_phone_number(contact, reply[8], PHONE_ID_WORK);
DBG("contact %p", contact);
- phonebook_add_contact(vcards, contact, params->filter, params->format);
- phonebook_contact_free(contact);
-
+ /* Adding contacts data to wrapper struct - this data will be used to
+ * generate vcard list */
+ if (!cdata_present) {
+ contact_data = g_new0(struct contact_data, 1);
+ contact_data->contact = contact;
+ contact_data->id = g_strdup(reply[CONTACTS_ID_COL]);
+ data->contacts = g_slist_append(data->contacts, contact_data);
+ }
return;
done:
+ vcards = gen_vcards(data->contacts, params);
+
if (num_fields == 0)
data->cb(vcards->str, vcards->len, data->index, 0,
data->user_data);
+ g_slist_free(data->contacts);
g_string_free(vcards, TRUE);
g_free(data);
}
@@ -775,10 +865,10 @@ int phonebook_pull(const char *name, const struct apparam_field *params,
return -ENOENT;
data = g_new0(struct phonebook_data, 1);
- data->vcards = g_string_new(NULL);
data->params = params;
data->user_data = user_data;
data->cb = cb;
+ data->contacts = NULL;
return query_tracker(query, 20, pull_contacts, data);
}
@@ -794,11 +884,11 @@ int phonebook_get_entry(const char *folder, const char *id,
DBG("folder %s id %s", folder, id);
data = g_new0(struct phonebook_data, 1);
- data->vcards = g_string_new(NULL);
data->user_data = user_data;
data->params = params;
data->cb = cb;
data->vcardentry = TRUE;
+ data->contacts = NULL;
query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id, id,
id, id, id, id, id, id, id);
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox