* [PATCH] hciattach: send hci commands after hci socket bring up
From: Suraj Sumangala @ 2010-11-19 5:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
This patch makes The Atheros AR300x specific initialization code
to send power management command over HCI socket after bringing up
the device.
---
tools/hciattach_ath3k.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/hciattach_ath3k.c b/tools/hciattach_ath3k.c
index b891506..70ade30 100644
--- a/tools/hciattach_ath3k.c
+++ b/tools/hciattach_ath3k.c
@@ -884,6 +884,8 @@ int ath3k_post(int fd, int pm)
int dev_id, dd;
struct timespec tm = { 0, 50000 };
+ sleep(1);
+
dev_id = ioctl(fd, HCIUARTGETDEVICE, 0);
if (dev_id < 0) {
perror("cannot get device id");
@@ -896,11 +898,15 @@ int ath3k_post(int fd, int pm)
return dd;
}
- sleep(2);
+ if (ioctl(dd, HCIDEVUP, dev_id) < 0 && errno != EALREADY) {
+ perror("hci down:Power management Disabled");
+ hci_close_dev(dd);
+ return -1;
+ }
/* send vendor specific command with Sleep feature Enabled */
if (hci_send_cmd(dd, OGF_VENDOR_CMD, HCI_SLEEP_CMD_OCF, 1, &pm) < 0)
- perror("Power management Disabled");
+ perror("PM command failed, power management Disabled");
nanosleep(&tm, NULL);
hci_close_dev(dd);
--
1.7.0.4
^ permalink raw reply related
* Re: New Broadcom chip in W510
From: Lu Ran @ 2010-11-19 6:08 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <201009190926.51131.hephooey@gmail.com>
Hi,
I have made some progress today, appearently 28 is ENOSPC, meaning the usb
host controller does not have enough bandwidth for the device. Indeed when I
unplug my usb mouse I can have playback (mic is still missing with ENOSPC). Is
there a way to reduce the package size from btusb, the mouse is the only
device I can remove, there are a internal camera and figure print reader always
connected.
--
Best Regards,
LR
On Sunday 19 September 2010 09:26:51 Lu Ran wrote:
> Hi all,
>
> I am having trouble to make my headset work in my new W510, it works fine
> in an T61, with has almost identical software and setup with the new W510.
> The only difference is I am now using a pure 64 bit system, while the old
> T61 is a 32 bit one, and the bluetooth chip is different. the id of the
> chip in T61 is 0A5C:2110, while W510 has a chip from Broadcom with id
> 0A5C:217F. I noticed there is a SCO fix for 0A5C:2110 in btusb.c. I tried
> to copy the line and change the id to 0A5C:217F, but nothing changes. The
> headset can pair with the laptop with no problem, but there seems to be no
> data transmition. And I get a lot error messages in dmesg output like
> this:
>
> btusb_submit_isoc_urb: hci0 urb ffff880060136e00 submission failed (28)
>
> and
>
> btusb_send_frame: hci0 urb ffff8801320e1a00 submission failed
>
> the output of "hciconfig hci0 version" is
>
> hci0: Type: BR/EDR Bus: USB
> BD Address: 70:F3:95:34:2F:29 ACL MTU: 1021:8 SCO MTU: 64:8
> HCI Version: 2.1 (0x4) Revision: 0x168
> LMP Version: 2.1 (0x4) Subversion: 0x4203
> Manufacturer: Broadcom Corporation (15)
>
> And the output of "lsusb -v" is in the attachment. I will try to provide
> any other information you need to analyse the problem.
^ permalink raw reply
* [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
From: Sheldon Demario @ 2010-11-19 13:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sheldon Demario
Sub-procedure used to read a Characteristic Value when the client
only knows the characteristic UUID and doesn't know the handle.
More than one handle and attribute value pair can be returned,
it is up to the user define the handles range based on the service
handles range.
Usage example:
$gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
---
attrib/gatt.c | 15 ++++++++++++---
attrib/gatt.h | 4 ++++
attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/attrib/gatt.c b/attrib/gatt.c
index 2c87daf..bca8b49 100644
--- a/attrib/gatt.c
+++ b/attrib/gatt.c
@@ -74,13 +74,22 @@ guint gatt_discover_primary(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_discover_char(GAttrib *attrib, uint16_t start, uint16_t end,
GAttribResultFunc func, gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
uuid_t uuid;
- guint16 plen;
sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
- plen = enc_read_by_type_req(start, end, &uuid, pdu, sizeof(pdu));
+ return gatt_read_char_by_uuid(attrib, start, end, &uuid, func,
+ user_data);
+}
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data)
+{
+ uint8_t pdu[ATT_DEFAULT_MTU];
+ guint16 plen;
+
+ plen = enc_read_by_type_req(start, end, uuid, pdu, sizeof(pdu));
if (plen == 0)
return 0;
diff --git a/attrib/gatt.h b/attrib/gatt.h
index 4e7d88b..1e1e628 100644
--- a/attrib/gatt.h
+++ b/attrib/gatt.h
@@ -41,3 +41,7 @@ guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_write_cmd(GAttrib *attrib, uint16_t handle, uint8_t *value, int vlen,
GDestroyNotify notify, gpointer user_data);
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data);
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index e961431..d0ef6d3 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -398,10 +398,49 @@ done:
g_main_loop_quit(event_loop);
}
+static void char_read_by_uuid_cb(guint8 status, const guint8 *pdu,
+ guint16 plen, gpointer user_data)
+{
+ struct att_data_list *list;
+ int i;
+
+ if (status != 0) {
+ g_printerr("Read characteristics by UUID failed: %s\n",
+ att_ecode2str(status));
+ goto done;
+ }
+
+ list = dec_read_by_type_resp(pdu, plen);
+ if (list == NULL)
+ goto done;
+
+ for (i = 0; i < list->num; i++) {
+ uint8_t *value = list->data[i];
+ int j;
+
+ g_print("handle: 0x%04x \t value: ", att_get_u16(value));
+ value += 2;
+ for (j = 0; j < list->len - 2; j++, value++)
+ g_print("%02x ", *value);
+ g_print("\n");
+ }
+
+ att_data_list_free(list);
+
+done:
+ g_main_loop_quit(event_loop);
+}
+
static gboolean characteristics_read(gpointer user_data)
{
GAttrib *attrib = user_data;
+ if (opt_uuid != NULL) {
+ gatt_read_char_by_uuid(attrib, opt_start, opt_end, opt_uuid,
+ char_read_by_uuid_cb, attrib);
+ return FALSE;
+ }
+
if (opt_handle <= 0) {
g_printerr("A valid handle is required\n");
g_main_loop_quit(event_loop);
--
1.7.3.2
^ permalink raw reply related
* [PATCH] Extract flags from advertising data
From: Bruna Moreira @ 2010-11-19 13:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bruna Moreira
These flags will be used to decide if GATT service discovery will happen
over LE (for single mode devices) or BR/EDR (for dual mode and non-LE
devices).
---
src/adapter.c | 14 ++++++++++++++
src/adapter.h | 1 +
src/sdpd.h | 10 ++++++++++
3 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 8136229..648d2a8 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3053,6 +3053,18 @@ static struct remote_dev_info *get_found_dev(struct btd_adapter *adapter,
return dev;
}
+static uint8_t extract_eir_flags(uint8_t *eir_data)
+{
+ if (eir_data[0] == 0)
+ return 0;
+
+ if (eir_data[1] != EIR_FLAGS)
+ return 0;
+
+ /* For now, only one octet is used for flags */
+ return eir_data[2];
+}
+
void adapter_update_device_from_info(struct btd_adapter *adapter,
le_advertising_info *info)
{
@@ -3084,6 +3096,8 @@ void adapter_update_device_from_info(struct btd_adapter *adapter,
g_free(dev->name);
dev->name = tmp_name;
}
+
+ dev->flags = extract_eir_flags(info->data);
}
/* FIXME: check if other information was changed before emitting the
diff --git a/src/adapter.h b/src/adapter.h
index 4af69b3..3a67539 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -74,6 +74,7 @@ struct remote_dev_info {
GSList *services;
uint8_t evt_type;
uint8_t bdaddr_type;
+ uint8_t flags;
};
struct hci_dev {
diff --git a/src/sdpd.h b/src/sdpd.h
index 5bab869..a46ad3c 100644
--- a/src/sdpd.h
+++ b/src/sdpd.h
@@ -36,6 +36,7 @@
#define EIR_DATA_LENGTH 240
+#define EIR_FLAGS 0x01 /* flags */
#define EIR_UUID16_SOME 0x02 /* 16-bit UUID, more available */
#define EIR_UUID16_ALL 0x03 /* 16-bit UUID, all listed */
#define EIR_UUID32_SOME 0x04 /* 32-bit UUID, more available */
@@ -47,6 +48,15 @@
#define EIR_TX_POWER 0x0A /* transmit power level */
#define EIR_DEVICE_ID 0x10 /* device ID */
+/* Flags Descriptions */
+#define EIR_LIM_DISC 0x01 /* LE Limited Discoverable Mode */
+#define EIR_GEN_DISC 0x02 /* LE General Discoverable Mode */
+#define EIR_BREDR_UNSUP 0x04 /* BR/EDR Not Supported */
+#define EIR_SIM_CONTROLLER 0x08 /* Simultaneous LE and BR/EDR to Same
+ Device Capable (Controller) */
+#define EIR_SIM_HOST 0x10 /* Simultaneous LE and BR/EDR to Same
+ Device Capable (Host) */
+
typedef struct request {
bdaddr_t device;
bdaddr_t bdaddr;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Merge service UUIDs from different BR/EDR EIR data
From: Anderson Lizardo @ 2010-11-19 14:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
For LE devices, service UUIDs present in advertising data are merged
into a single list. This change makes the same thing for BR/EDR devices.
---
src/adapter.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 8136229..c650a63 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3004,12 +3004,6 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
} else
alias = g_strdup(dev->alias);
- if (dev->services) {
- g_slist_foreach(dev->services, (GFunc) g_free, NULL);
- g_slist_free(dev->services);
- dev->services = NULL;
- }
-
emit_device_found(adapter->path, paddr,
"Address", DBUS_TYPE_STRING, &paddr,
"Class", DBUS_TYPE_UINT32, &dev->class,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] Avoid reallocations of services UUID array
From: Anderson Lizardo @ 2010-11-19 14:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1290178241-8358-1-git-send-email-anderson.lizardo@openbossa.org>
The array of service UUIDs used by the DeviceFound signal contains the
same information from the GSList of services. Instead of reallocating
this array on each signal, store it on the remote_dev_info structure and
only reallocate it if there are new UUIDs.
---
src/adapter.c | 17 ++++++++---------
src/adapter.h | 3 ++-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index c650a63..1e51d11 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2964,7 +2964,6 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
dbus_bool_t paired = FALSE;
dbus_int16_t rssi = dev->rssi;
char *alias;
- char **uuids = NULL;
size_t uuid_count;
ba2str(&dev->bdaddr, peer_addr);
@@ -2977,9 +2976,11 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
/* Extract UUIDs from extended inquiry response if any */
dev->services = get_eir_uuids(eir_data, eir_length, dev->services);
uuid_count = g_slist_length(dev->services);
-
- if (dev->services)
- uuids = strlist2array(dev->services);
+ if (dev->services && dev->uuid_count != uuid_count) {
+ g_strfreev(dev->uuids);
+ dev->uuids = strlist2array(dev->services);
+ dev->uuid_count = uuid_count;
+ }
if (dev->le) {
emit_device_found(adapter->path, paddr,
@@ -2987,9 +2988,8 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"RSSI", DBUS_TYPE_INT16, &rssi,
"Name", DBUS_TYPE_STRING, &dev->name,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
- "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
- NULL);
- g_strfreev(uuids);
+ "UUIDs", DBUS_TYPE_ARRAY, &dev->uuids,
+ dev->uuid_count, NULL);
return;
}
@@ -3013,11 +3013,10 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"Alias", DBUS_TYPE_STRING, &alias,
"LegacyPairing", DBUS_TYPE_BOOLEAN, &dev->legacy,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
- "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
+ "UUIDs", DBUS_TYPE_ARRAY, &dev->uuids, dev->uuid_count,
NULL);
g_free(alias);
- g_strfreev(uuids);
}
static struct remote_dev_info *get_found_dev(struct btd_adapter *adapter,
diff --git a/src/adapter.h b/src/adapter.h
index 4af69b3..955bb9a 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -70,7 +70,8 @@ struct remote_dev_info {
dbus_bool_t legacy;
name_status_t name_status;
gboolean le;
- /* LE adv data */
+ char **uuids;
+ size_t uuid_count;
GSList *services;
uint8_t evt_type;
uint8_t bdaddr_type;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] Avoid reallocations of services UUID array
From: Anderson Lizardo @ 2010-11-19 14:53 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1290178241-8358-2-git-send-email-anderson.lizardo@openbossa.org>
On Fri, Nov 19, 2010 at 10:50 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> The array of service UUIDs used by the DeviceFound signal contains the
> same information from the GSList of services. Instead of reallocating
> this array on each signal, store it on the remote_dev_info structure and
> only reallocate it if there are new UUIDs.
Oops, just noticed I forgot to free the dev->uuids array. Will send a
fixed patch ASAP.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH v2 2/2] Avoid reallocations of services UUID array
From: Anderson Lizardo @ 2010-11-19 14:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
The array of service UUIDs used by the DeviceFound signal contains the
same information from the GSList of services. Instead of reallocating
this array on each signal, store it on the remote_dev_info structure and
only reallocate it if there are new UUIDs.
---
src/adapter.c | 18 +++++++++---------
src/adapter.h | 3 ++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index c650a63..4fe8276 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -204,6 +204,7 @@ static void dev_info_free(struct remote_dev_info *dev)
g_free(dev->alias);
g_slist_foreach(dev->services, (GFunc) g_free, NULL);
g_slist_free(dev->services);
+ g_strfreev(dev->uuids);
g_free(dev);
}
@@ -2964,7 +2965,6 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
dbus_bool_t paired = FALSE;
dbus_int16_t rssi = dev->rssi;
char *alias;
- char **uuids = NULL;
size_t uuid_count;
ba2str(&dev->bdaddr, peer_addr);
@@ -2977,9 +2977,11 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
/* Extract UUIDs from extended inquiry response if any */
dev->services = get_eir_uuids(eir_data, eir_length, dev->services);
uuid_count = g_slist_length(dev->services);
-
- if (dev->services)
- uuids = strlist2array(dev->services);
+ if (dev->services && dev->uuid_count != uuid_count) {
+ g_strfreev(dev->uuids);
+ dev->uuids = strlist2array(dev->services);
+ dev->uuid_count = uuid_count;
+ }
if (dev->le) {
emit_device_found(adapter->path, paddr,
@@ -2987,9 +2989,8 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"RSSI", DBUS_TYPE_INT16, &rssi,
"Name", DBUS_TYPE_STRING, &dev->name,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
- "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
- NULL);
- g_strfreev(uuids);
+ "UUIDs", DBUS_TYPE_ARRAY, &dev->uuids,
+ dev->uuid_count, NULL);
return;
}
@@ -3013,11 +3014,10 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"Alias", DBUS_TYPE_STRING, &alias,
"LegacyPairing", DBUS_TYPE_BOOLEAN, &dev->legacy,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
- "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
+ "UUIDs", DBUS_TYPE_ARRAY, &dev->uuids, dev->uuid_count,
NULL);
g_free(alias);
- g_strfreev(uuids);
}
static struct remote_dev_info *get_found_dev(struct btd_adapter *adapter,
diff --git a/src/adapter.h b/src/adapter.h
index 4af69b3..955bb9a 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -70,7 +70,8 @@ struct remote_dev_info {
dbus_bool_t legacy;
name_status_t name_status;
gboolean le;
- /* LE adv data */
+ char **uuids;
+ size_t uuid_count;
GSList *services;
uint8_t evt_type;
uint8_t bdaddr_type;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Add command line option to change BCSP rate
From: Johan Hedberg @ 2010-11-19 15:23 UTC (permalink / raw)
To: Wade Brown; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <6EBC2ED6C3CFDC428167C1FF4764F0710A96D8BE9A1A@SJEXBEC1.research.us.panasonic.com>
Hi,
On Thu, Nov 18, 2010, Wade Brown wrote:
> Currently when using bccmd to do any communication, the UART is always
> opened at 38.4kbps. Once the CSR has been initialized to any other
> speed, bccmd can no longer communicate with with the radio (unless by
> resetting it through rfkill). This patch adds a -b option allowing a
> user to manually set a different speed, with the default 38400 still in
> place.
>
> Usage example:
> $bccmd -t BCSP -b 921600 -d /dev/ttyHS1 chiprev
>
> ---
> tools/bccmd.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
> tools/csr.h | 3 ++-
> tools/csr_bcsp.c | 4 ++--
> 3 files changed, 44 insertions(+), 8 deletions(-)
The patch seems fine to me but I can't figure out how to apply it either
due to your mail client or your mail server. It's not sent inline and
the attachment isn't a complete git patch as such. Additionally there's
some strange winmail.dat attachment in the mail. Could you try resending
e.g. using git send-email?
Johan
^ permalink raw reply
* Re: [PATCH] hciattach: send hci commands after hci socket bring up
From: Johan Hedberg @ 2010-11-19 15:24 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1290145903-11452-1-git-send-email-suraj@atheros.com>
Hi,
On Fri, Nov 19, 2010, Suraj Sumangala wrote:
> This patch makes The Atheros AR300x specific initialization code
> to send power management command over HCI socket after bringing up
> the device.
>
> ---
> tools/hciattach_ath3k.c | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
From: Johan Hedberg @ 2010-11-19 15:25 UTC (permalink / raw)
To: Sheldon Demario; +Cc: linux-bluetooth
In-Reply-To: <1290173697-20097-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
On Fri, Nov 19, 2010, Sheldon Demario wrote:
> Sub-procedure used to read a Characteristic Value when the client
> only knows the characteristic UUID and doesn't know the handle.
> More than one handle and attribute value pair can be returned,
> it is up to the user define the handles range based on the service
> handles range.
>
> Usage example:
> $gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
> ---
> attrib/gatt.c | 15 ++++++++++++---
> attrib/gatt.h | 4 ++++
> attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+), 3 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Extract flags from advertising data
From: Johan Hedberg @ 2010-11-19 15:28 UTC (permalink / raw)
To: Bruna Moreira; +Cc: linux-bluetooth
In-Reply-To: <1290175048-16026-1-git-send-email-bruna.moreira@openbossa.org>
Hi Bruna,
On Fri, Nov 19, 2010, Bruna Moreira wrote:
> These flags will be used to decide if GATT service discovery will happen
> over LE (for single mode devices) or BR/EDR (for dual mode and non-LE
> devices).
> ---
> src/adapter.c | 14 ++++++++++++++
> src/adapter.h | 1 +
> src/sdpd.h | 10 ++++++++++
> 3 files changed, 25 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Merge service UUIDs from different BR/EDR EIR data
From: Johan Hedberg @ 2010-11-19 15:29 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1290178241-8358-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Fri, Nov 19, 2010, Anderson Lizardo wrote:
> For LE devices, service UUIDs present in advertising data are merged
> into a single list. This change makes the same thing for BR/EDR devices.
> ---
> src/adapter.c | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v2 2/2] Avoid reallocations of services UUID array
From: Johan Hedberg @ 2010-11-19 15:30 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1290178759-9270-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Fri, Nov 19, 2010, Anderson Lizardo wrote:
> The array of service UUIDs used by the DeviceFound signal contains the
> same information from the GSList of services. Instead of reallocating
> this array on each signal, store it on the remote_dev_info structure and
> only reallocate it if there are new UUIDs.
> ---
> src/adapter.c | 18 +++++++++---------
> src/adapter.h | 3 ++-
> 2 files changed, 11 insertions(+), 10 deletions(-)
This one has also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Pull request git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
From: Luiz Augusto von Dentz @ 2010-11-19 16:31 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Those changes fixes several issues when doing a Device.Disconnect
while some audio profile is still connecting. I did some cleanups to
make it easier to track references and reuse more code, and also did a
lot o testing to make sure it doesn't cause any regression for cases
where the client is using Media API or unix socket.
The following changes since commit 55685d2037d33ed29ed7365150fd14b5326690fb:
Fix minor typo (2010-11-19 17:39:15 +0200)
are available in the git repository at:
git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
Luiz Augusto von Dentz (9):
Cleanup a2dp setup code
Cleanup a2dp_cancel code
Fix not removing all timers when user request to disconnect audio
Fix abort not being send when the state is idle
Fix reference count of a2dp stream setup
Add debug logs for state changes on sink
Fix possible crashes when attempting to connect avdtp
Fix not dropping avdtp session reference when cancelling stream setup
Fix not indicating disconnected state when connecting to avdtp
audio/a2dp.c | 258 +++++++++++++++++++++++++------------------------------
audio/avdtp.c | 26 +++---
audio/device.c | 36 ++++----
audio/sink.c | 13 +++
4 files changed, 163 insertions(+), 170 deletions(-)
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: Pull request git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
From: Johan Hedberg @ 2010-11-19 16:50 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimQB+-odX2Yw+gxrdd2SBajxZ3nswtffW+L-g9_@mail.gmail.com>
Hi Luiz,
On Fri, Nov 19, 2010, Luiz Augusto von Dentz wrote:
> Those changes fixes several issues when doing a Device.Disconnect
> while some audio profile is still connecting. I did some cleanups to
> make it easier to track references and reuse more code, and also did a
> lot o testing to make sure it doesn't cause any regression for cases
> where the client is using Media API or unix socket.
>
> The following changes since commit 55685d2037d33ed29ed7365150fd14b5326690fb:
>
> Fix minor typo (2010-11-19 17:39:15 +0200)
>
> are available in the git repository at:
> git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
>
> Luiz Augusto von Dentz (9):
> Cleanup a2dp setup code
> Cleanup a2dp_cancel code
> Fix not removing all timers when user request to disconnect audio
> Fix abort not being send when the state is idle
> Fix reference count of a2dp stream setup
> Add debug logs for state changes on sink
> Fix possible crashes when attempting to connect avdtp
> Fix not dropping avdtp session reference when cancelling stream setup
> Fix not indicating disconnected state when connecting to avdtp
>
> audio/a2dp.c | 258 +++++++++++++++++++++++++------------------------------
> audio/avdtp.c | 26 +++---
> audio/device.c | 36 ++++----
> audio/sink.c | 13 +++
> 4 files changed, 163 insertions(+), 170 deletions(-)
Thanks! The patches have been pushed upstream.
Johan
^ permalink raw reply
* RE: [PATCH] Add command line option to change BCSP rate
From: Wade Brown @ 2010-11-19 19:26 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20101119152346.GA28815@jh-x301>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
Johan,
Sorry about that, I seem to be a bit behind the times. My git version is missing that feature, and evolution as a mail client seems to love attaching other bits. If this fails I'll work on updating my system and mail clients.
--
Wade Brown
________________________________________
From: Johan Hedberg [johan.hedberg@gmail.com]
Sent: Friday, November 19, 2010 7:23 AM
To: Wade Brown
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] Add command line option to change BCSP rate
Hi,
On Thu, Nov 18, 2010, Wade Brown wrote:
> Currently when using bccmd to do any communication, the UART is always
> opened at 38.4kbps. Once the CSR has been initialized to any other
> speed, bccmd can no longer communicate with with the radio (unless by
> resetting it through rfkill). This patch adds a -b option allowing a
> user to manually set a different speed, with the default 38400 still in
> place.
>
> Usage example:
> $bccmd -t BCSP -b 921600 -d /dev/ttyHS1 chiprev
>
> ---
> tools/bccmd.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
> tools/csr.h | 3 ++-
> tools/csr_bcsp.c | 4 ++--
> 3 files changed, 44 insertions(+), 8 deletions(-)
The patch seems fine to me but I can't figure out how to apply it either
due to your mail client or your mail server. It's not sent inline and
the attachment isn't a complete git patch as such. Additionally there's
some strange winmail.dat attachment in the mail. Could you try resending
e.g. using git send-email?
Johan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bccmd-set-bcsp-rate.patch --]
[-- Type: text/x-patch; name="bccmd-set-bcsp-rate.patch", Size: 4615 bytes --]
tools/bccmd.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
tools/csr.h | 3 ++-
tools/csr_bcsp.c | 4 ++--
3 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/tools/bccmd.c b/tools/bccmd.c
index 686e858..5cb9255 100644
--- a/tools/bccmd.c
+++ b/tools/bccmd.c
@@ -59,7 +59,7 @@
#define CSR_TYPE_ARRAY CSR_TYPE_COMPLEX
#define CSR_TYPE_BDADDR CSR_TYPE_COMPLEX
-static inline int transport_open(int transport, char *device)
+static inline int transport_open(int transport, char *device, speed_t bcsp_rate)
{
switch (transport) {
case CSR_TRANSPORT_HCI:
@@ -69,7 +69,7 @@ static inline int transport_open(int transport, char *device)
return csr_open_usb(device);
#endif
case CSR_TRANSPORT_BCSP:
- return csr_open_bcsp(device);
+ return csr_open_bcsp(device, bcsp_rate);
case CSR_TRANSPORT_H4:
return csr_open_h4(device);
case CSR_TRANSPORT_3WIRE:
@@ -1109,6 +1109,7 @@ static void usage(void)
printf("Options:\n"
"\t-t <transport> Select the transport\n"
"\t-d <device> Select the device\n"
+ "\t-b <bcsp rate> Select the bcsp transfer rate\n"
"\t-h, --help Display help\n"
"\n");
@@ -1137,6 +1138,7 @@ static void usage(void)
static struct option main_options[] = {
{ "transport", 1, 0, 't' },
{ "device", 1, 0, 'd' },
+ { "bcsprate", 1, 0, 'b'},
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
};
@@ -1145,8 +1147,9 @@ int main(int argc, char *argv[])
{
char *device = NULL;
int i, err, opt, transport = CSR_TRANSPORT_HCI;
+ speed_t bcsp_rate = B38400;
- while ((opt=getopt_long(argc, argv, "+t:d:i:h", main_options, NULL)) != EOF) {
+ while ((opt=getopt_long(argc, argv, "+t:d:i:b:h", main_options, NULL)) != EOF) {
switch (opt) {
case 't':
if (!strcasecmp(optarg, "hci"))
@@ -1171,7 +1174,39 @@ int main(int argc, char *argv[])
case 'i':
device = strdup(optarg);
break;
-
+ case 'b':
+ switch (atoi(optarg)) {
+ case 9600: bcsp_rate = B9600; break;
+ case 19200: bcsp_rate = B19200; break;
+ case 38400: bcsp_rate = B38400; break;
+ case 57600: bcsp_rate = B57600; break;
+ case 115200: bcsp_rate = B115200; break;
+ case 230400: bcsp_rate = B230400; break;
+ case 460800: bcsp_rate = B460800; break;
+ case 500000: bcsp_rate = B500000; break;
+ case 576000: bcsp_rate = B576000; break;
+ case 921600: bcsp_rate = B921600; break;
+ case 1000000: bcsp_rate = B1000000; break;
+ case 1152000: bcsp_rate = B1152000; break;
+ case 1500000: bcsp_rate = B1500000; break;
+ case 2000000: bcsp_rate = B2000000; break;
+#ifdef B2500000
+ case 2500000: bcsp_rate = B2500000; break;
+#endif
+#ifdef B3000000
+ case 3000000: bcsp_rate = B3000000; break;
+#endif
+#ifdef B3500000
+ case 3500000: bcsp_rate = B3500000; break;
+#endif
+#ifdef B4000000
+ case 4000000: bcsp_rate = B4000000; break;
+#endif
+ default:
+ printf("Unknown BCSP baud rate specified, defaulting to 38400bps\n");
+ bcsp_rate = B38400;
+ }
+ break;
case 'h':
default:
usage();
@@ -1188,7 +1223,7 @@ int main(int argc, char *argv[])
exit(1);
}
- if (transport_open(transport, device) < 0)
+ if (transport_open(transport, device, bcsp_rate) < 0)
exit(1);
if (device)
diff --git a/tools/csr.h b/tools/csr.h
index 1d70491..8b94d7b 100644
--- a/tools/csr.h
+++ b/tools/csr.h
@@ -22,6 +22,7 @@
*/
#include <stdint.h>
+#include <termios.h>
#define CSR_VARID_PS_CLR_ALL 0x000b /* valueless */
#define CSR_VARID_PS_FACTORY_SET 0x000c /* valueless */
@@ -519,7 +520,7 @@ int csr_read_usb(uint16_t varid, uint8_t *value, uint16_t length);
int csr_write_usb(uint16_t varid, uint8_t *value, uint16_t length);
void csr_close_usb(void);
-int csr_open_bcsp(char *device);
+int csr_open_bcsp(char *device, speed_t bcsp_rate);
int csr_read_bcsp(uint16_t varid, uint8_t *value, uint16_t length);
int csr_write_bcsp(uint16_t varid, uint8_t *value, uint16_t length);
void csr_close_bcsp(void);
diff --git a/tools/csr_bcsp.c b/tools/csr_bcsp.c
index e551311..df247a2 100644
--- a/tools/csr_bcsp.c
+++ b/tools/csr_bcsp.c
@@ -46,7 +46,7 @@ static uint8_t send_buffer[512];
static struct ubcsp_packet receive_packet;
static uint8_t receive_buffer[512];
-int csr_open_bcsp(char *device)
+int csr_open_bcsp(char *device, speed_t bcsp_rate)
{
struct termios ti;
uint8_t delay, activity = 0x00;
@@ -84,7 +84,7 @@ int csr_open_bcsp(char *device)
ti.c_cc[VMIN] = 1;
ti.c_cc[VTIME] = 0;
- cfsetospeed(&ti, B38400);
+ cfsetospeed(&ti, bcsp_rate);
if (tcsetattr(fd, TCSANOW, &ti) < 0) {
fprintf(stderr, "Can't change port settings: %s (%d)\n",
^ permalink raw reply related
* Re: [PATCH] Add command line option to change BCSP rate
From: Johan Hedberg @ 2010-11-19 19:44 UTC (permalink / raw)
To: Wade Brown; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <6EBC2ED6C3CFDC428167C1FF4764F0710A96D8BEB33E@SJEXBEC1.research.us.panasonic.com>
Hi Wade,
Btw, please don't top-post on this list.
On Fri, Nov 19, 2010, Wade Brown wrote:
> Sorry about that, I seem to be a bit behind the times. My git version
> is missing that feature, and evolution as a mail client seems to love
> attaching other bits. If this fails I'll work on updating my system
> and mail clients.
You need to send something I can give to git am, i.e. something formated
using git format-patch.
Johan
^ permalink raw reply
* RE: [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
From: Mike Tsai @ 2010-11-20 0:49 UTC (permalink / raw)
To: Sheldon Demario, linux-bluetooth@vger.kernel.org
In-Reply-To: <1290173697-20097-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Sheldon Demario
Sent: Friday, November 19, 2010 5:35 AM
To: linux-bluetooth@vger.kernel.org
Cc: Sheldon Demario
Subject: [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
Sub-procedure used to read a Characteristic Value when the client
only knows the characteristic UUID and doesn't know the handle.
More than one handle and attribute value pair can be returned,
it is up to the user define the handles range based on the service
handles range.
Usage example:
$gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
---
attrib/gatt.c | 15 ++++++++++++---
attrib/gatt.h | 4 ++++
attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/attrib/gatt.c b/attrib/gatt.c
index 2c87daf..bca8b49 100644
--- a/attrib/gatt.c
+++ b/attrib/gatt.c
@@ -74,13 +74,22 @@ guint gatt_discover_primary(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_discover_char(GAttrib *attrib, uint16_t start, uint16_t end,
GAttribResultFunc func, gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
uuid_t uuid;
- guint16 plen;
sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
- plen = enc_read_by_type_req(start, end, &uuid, pdu, sizeof(pdu));
+ return gatt_read_char_by_uuid(attrib, start, end, &uuid, func,
+ user_data);
+}
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data)
+{
+ uint8_t pdu[ATT_DEFAULT_MTU];
+ guint16 plen;
+
+ plen = enc_read_by_type_req(start, end, uuid, pdu, sizeof(pdu));
if (plen == 0)
return 0;
diff --git a/attrib/gatt.h b/attrib/gatt.h
index 4e7d88b..1e1e628 100644
--- a/attrib/gatt.h
+++ b/attrib/gatt.h
@@ -41,3 +41,7 @@ guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_write_cmd(GAttrib *attrib, uint16_t handle, uint8_t *value, int vlen,
GDestroyNotify notify, gpointer user_data);
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data);
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index e961431..d0ef6d3 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -398,10 +398,49 @@ done:
g_main_loop_quit(event_loop);
}
+static void char_read_by_uuid_cb(guint8 status, const guint8 *pdu,
+ guint16 plen, gpointer user_data)
+{
+ struct att_data_list *list;
+ int i;
+
+ if (status != 0) {
+ g_printerr("Read characteristics by UUID failed: %s\n",
+ att_ecode2str(status));
+ goto done;
+ }
+
+ list = dec_read_by_type_resp(pdu, plen);
+ if (list == NULL)
+ goto done;
+
+ for (i = 0; i < list->num; i++) {
+ uint8_t *value = list->data[i];
+ int j;
+
+ g_print("handle: 0x%04x \t value: ", att_get_u16(value));
+ value += 2;
+ for (j = 0; j < list->len - 2; j++, value++)
+ g_print("%02x ", *value);
+ g_print("\n");
+ }
+
+ att_data_list_free(list);
+
+done:
+ g_main_loop_quit(event_loop);
+}
+
[MTsai] in your call back function here, you assume that "read_by_type_request" operation has completed. In the case of example with uuid=0x2a00 (device name), this is probably true. However, if there are multiple characteristics with same UUID within the database, then server probably has not sent all the characteristic value back yet, shall you check to see if the reading is really completed (comparing the handle), otherwise, issue another read_by_type_request with starting handle = attribute handle+1?
static gboolean characteristics_read(gpointer user_data)
{
GAttrib *attrib = user_data;
+ if (opt_uuid != NULL) {
+ gatt_read_char_by_uuid(attrib, opt_start, opt_end, opt_uuid,
+ char_read_by_uuid_cb, attrib);
+ return FALSE;
+ }
+
if (opt_handle <= 0) {
g_printerr("A valid handle is required\n");
g_main_loop_quit(event_loop);
--
1.7.3.2
--
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 related
* RE: [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
From: Mike Tsai @ 2010-11-20 1:36 UTC (permalink / raw)
To: Sheldon Demario, linux-bluetooth@vger.kernel.org
In-Reply-To: <1290173697-20097-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Sheldon Demario
Sent: Friday, November 19, 2010 5:35 AM
To: linux-bluetooth@vger.kernel.org
Cc: Sheldon Demario
Subject: [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
Sub-procedure used to read a Characteristic Value when the client
only knows the characteristic UUID and doesn't know the handle.
More than one handle and attribute value pair can be returned,
it is up to the user define the handles range based on the service
handles range.
Usage example:
$gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
---
attrib/gatt.c | 15 ++++++++++++---
attrib/gatt.h | 4 ++++
attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/attrib/gatt.c b/attrib/gatt.c
index 2c87daf..bca8b49 100644
--- a/attrib/gatt.c
+++ b/attrib/gatt.c
@@ -74,13 +74,22 @@ guint gatt_discover_primary(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_discover_char(GAttrib *attrib, uint16_t start, uint16_t end,
GAttribResultFunc func, gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
uuid_t uuid;
- guint16 plen;
sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
- plen = enc_read_by_type_req(start, end, &uuid, pdu, sizeof(pdu));
+ return gatt_read_char_by_uuid(attrib, start, end, &uuid, func,
+ user_data);
+}
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data)
+{
+ uint8_t pdu[ATT_DEFAULT_MTU];
+ guint16 plen;
+
+ plen = enc_read_by_type_req(start, end, uuid, pdu, sizeof(pdu));
if (plen == 0)
return 0;
diff --git a/attrib/gatt.h b/attrib/gatt.h
index 4e7d88b..1e1e628 100644
--- a/attrib/gatt.h
+++ b/attrib/gatt.h
@@ -41,3 +41,7 @@ guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_write_cmd(GAttrib *attrib, uint16_t handle, uint8_t *value, int vlen,
GDestroyNotify notify, gpointer user_data);
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data);
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index e961431..d0ef6d3 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -398,10 +398,49 @@ done:
g_main_loop_quit(event_loop);
}
+static void char_read_by_uuid_cb(guint8 status, const guint8 *pdu,
+ guint16 plen, gpointer user_data)
+{
+ struct att_data_list *list;
+ int i;
+
+ if (status != 0) {
+ g_printerr("Read characteristics by UUID failed: %s\n",
+ att_ecode2str(status));
+ goto done;
+ }
+
+ list = dec_read_by_type_resp(pdu, plen);
+ if (list == NULL)
+ goto done;
+
+ for (i = 0; i < list->num; i++) {
+ uint8_t *value = list->data[i];
+ int j;
+
+ g_print("handle: 0x%04x \t value: ", att_get_u16(value));
+ value += 2;
+ for (j = 0; j < list->len - 2; j++, value++)
+ g_print("%02x ", *value);
+ g_print("\n");
+ }
+
+ att_data_list_free(list);
+
+done:
+ g_main_loop_quit(event_loop);
+}
+
[MTsai] in your call back function here, you assume that "read_by_type_request" operation has completed. In the case of example with uuid=0x2a00 (device name), this is probably true. However, if there are multiple characteristics with same UUID within the database, then server probably has not sent all the characteristic value back yet, shall you check to see if the reading is really completed (comparing the handle), otherwise, issue another read_by_type_request with starting handle = attribute handle+1?
static gboolean characteristics_read(gpointer user_data)
{
GAttrib *attrib = user_data;
+ if (opt_uuid != NULL) {
+ gatt_read_char_by_uuid(attrib, opt_start, opt_end, opt_uuid,
+ char_read_by_uuid_cb, attrib);
+ return FALSE;
+ }
+
if (opt_handle <= 0) {
g_printerr("A valid handle is required\n");
g_main_loop_quit(event_loop);
--
1.7.3.2
--
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 related
* [PATCH] Remove parameter entered from the DisplayPasskey agent method
From: Jose Antonio Santos Cadenas @ 2010-11-21 12:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
In the current method implementation the parameter is not used.
---
doc/agent-api.txt | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/doc/agent-api.txt b/doc/agent-api.txt
index d8d35c0..1ddd290 100644
--- a/doc/agent-api.txt
+++ b/doc/agent-api.txt
@@ -42,14 +42,11 @@ Methods void Release()
Possible errors: org.bluez.Error.Rejected
org.bluez.Error.Canceled
- void DisplayPasskey(object device, uint32 passkey, uint8 entered)
+ void DisplayPasskey(object device, uint32 passkey)
This method gets called when the service daemon
needs to display a passkey for an authentication.
- The entered parameter indicates the number of already
- typed keys on the remote side.
-
An empty reply should be returned. When the passkey
needs no longer to be displayed, the Cancel method
of the agent will be called.
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Remove parameter entered from the DisplayPasskey agent method
From: Johan Hedberg @ 2010-11-21 13:14 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1290343578-986-1-git-send-email-santoscadenas@gmail.com>
Hi Jose,
On Sun, Nov 21, 2010, Jose Antonio Santos Cadenas wrote:
> In the current method implementation the parameter is not used.
> ---
> doc/agent-api.txt | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
Do you actually have a BT 2.1 keyboard to test this with? The right fix
is to fix the code and not the spec since we do want the UI to get the
hints about entered characters.
Johan
^ permalink raw reply
* [PATCH] Fix error handling for l2cap_init()
From: Anderson Lizardo @ 2010-11-21 15:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
create_singlethread_workqueue() may fail with errors such as -ENOMEM. If
this happens, the return value is not set to a negative value and the
module load will succeed. It will then crash on module unload because of
a destroy_workqueue() call on a NULL pointer.
Additionally, the _busy_wq workqueue is not being destroyed if any
errors happen on l2cap_init().
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
---
net/bluetooth/l2cap.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 18a802c..7980e24 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4875,8 +4875,10 @@ static int __init l2cap_init(void)
return err;
_busy_wq = create_singlethread_workqueue("l2cap");
- if (!_busy_wq)
- goto error;
+ if (!_busy_wq) {
+ err = -ENOMEM;
+ goto error_busy_wq;
+ }
err = bt_sock_register(BTPROTO_L2CAP, &l2cap_sock_family_ops);
if (err < 0) {
@@ -4904,6 +4906,8 @@ static int __init l2cap_init(void)
return 0;
error:
+ destroy_workqueue(_busy_wq);
+error_busy_wq:
proto_unregister(&l2cap_proto);
return err;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Remove parameter entered from the DisplayPasskey agent method
From: Jose Antonio Santos Cadenas @ 2010-11-21 16:07 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <20101121131442.GA22320@jh-x301>
Hi Johan,
2010/11/21 Johan Hedberg <johan.hedberg@gmail.com>:
> Hi Jose,
>
> On Sun, Nov 21, 2010, Jose Antonio Santos Cadenas wrote:
>> In the current method implementation the parameter is not used.
>> ---
>> doc/agent-api.txt | 5 +----
>> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> Do you actually have a BT 2.1 keyboard to test this with?
I'm lost, why do I need a BT keyboard?
> The right fix
> is to fix the code and not the spec since we do want the UI to get the
> hints about entered characters.
I also think that an other way to correct this is to change the code
to follow the specification, but as I see that the specification
didn't have changes since 2008 I thought that was an obsolete
documentation, because in the source code there is no reference to the
entered parameter. Have you got any suggestions about the better way
to add this parameter in order to follow the API in the documentation?
Nevertheless I'll have a deeper look to the code looking for hints.
>
> Johan
>
Regards.
Jose.
^ permalink raw reply
* Re: [PATCH] Remove parameter entered from the DisplayPasskey agent method
From: Johan Hedberg @ 2010-11-21 19:25 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=_BVKOptuGTz8eoHPaTQrkr6-3oCK8mzJq4oea@mail.gmail.com>
Hi Jose,
On Sun, Nov 21, 2010, Jose Antonio Santos Cadenas wrote:
> > On Sun, Nov 21, 2010, Jose Antonio Santos Cadenas wrote:
> >> In the current method implementation the parameter is not used.
> >> ---
> >> doc/agent-api.txt | 5 +----
> >> 1 files changed, 1 insertions(+), 4 deletions(-)
> >
> > Do you actually have a BT 2.1 keyboard to test this with?
>
> I'm lost, why do I need a BT keyboard?
Because DisplayPasskey will only happen if the other side has
KeyboardOnly as its SSP IO capability.
> > The right fix
> > is to fix the code and not the spec since we do want the UI to get the
> > hints about entered characters.
>
> I also think that an other way to correct this is to change the code
> to follow the specification, but as I see that the specification
> didn't have changes since 2008 I thought that was an obsolete
> documentation, because in the source code there is no reference to the
> entered parameter. Have you got any suggestions about the better way
> to add this parameter in order to follow the API in the documentation?
> Nevertheless I'll have a deeper look to the code looking for hints.
The third parameter is supposed to be bound to the Keypress Notification
HCI event which should come when the remote side does a
HCI_Send_Keypress_Notification HCI command (again only a keyboard would
do something like this).
Johan
^ permalink raw reply
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