* [PATCH] TODO: Device Name Characteristic for Low Energy
From: Claudio Takahasi @ 2010-10-13 17:44 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
---
TODO | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 0a7b482..2c17c6b 100644
--- a/TODO
+++ b/TODO
@@ -14,6 +14,20 @@ Background
Higher complexity tasks should be refined into several lower complexity tasks
once the task is better understood.
+LE Generic Access Profile
+=========================
+
+- Device Name Characteristic is a GAP characteristic for Low Energy. This
+ characteristic shall be integrated/used in the discovery procedure. The
+ ideia is to report the value of this characteristic using DeviceFound signals.
+ Discussion with the community is needed before to start this task. Other GAP
+ characteristics for LE needs to follow a similar approach. It is not clear
+ if all GAP characteristics can be exposed using properties instead of a primary
+ service characteristics.
+ See Volume 3, Part C, section 12.1 for more information.
+
+ Priority: Low
+ Complexity: C2
ATT/GATT
========
--
1.7.3.1
^ permalink raw reply related
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Luis R. Rodriguez @ 2010-10-13 17:42 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Henry Ptasinski, Suraj Sumangala, Luis Rodriguez, David Woodhouse,
linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <1286964370.3316.6.camel@aeonflux>
On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Henry,
>
>> > > Marcel had answered me before. It makes sense to have same file name.
>> > > Other ways we end up changing the driver whenever there is a firmware
>> > > change.
>> >
>> > > > I last tried to document a thread we had over this here:
>> > > >
>> > > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
>> > > >
>> >
>> > Thanks, I've updated that link above to document bug fixing does not require
>> > a filename change.
>>
>> I don't really understand why you would not want to change the code revision
>> part of the filename.
>>
>> I totally agree that you don't want to change the driver every time the
>> firmware gets a bug fix, but wasn't that the whole point of splitting the name
>> into API and code revisions portions, and symlinking the file to one that just
>> has the API version?
>>
>> What's the issue with using the process as originally documented?
>
> as I stated before, for Bluetooth this makes no sense. You don't need
> API version numbers since the API is a STANDARD. It is called HCI. So
> please don't use API version numbers in the firmware files.
>
> I will reject firmware file versions for upstream drivers.
Does the HCI standard ever get improved upon? If so, how do devices
never get firmware updates that would allow them to use some newer HCI
APIs?
I've updated the documentation above for 802.11 and Bluetooth with the
above, please feel free to further extend it as you see fit.
Luis
^ permalink raw reply
* Re: [PATCH] TODO: Implement Server Characteristic Configuration
From: Johan Hedberg @ 2010-10-13 17:00 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286987833-25972-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 13, 2010, Claudio Takahasi wrote:
> ---
> TODO | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
And this one has also been pushed. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] TODO: Implement Client Characteristic Configuration
From: Johan Hedberg @ 2010-10-13 16:59 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286987650-25914-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 13, 2010, Claudio Takahasi wrote:
> ---
> TODO | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
Thanks. This one has also been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Disable automatic notification/indication in the attribute server
From: Johan Hedberg @ 2010-10-13 16:59 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286987539-25833-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 13, 2010, Claudio Takahasi wrote:
> Attribute server shall not send automatic indication/notification
> messages if the client didn't request them. Client shall use Client
> /Server Characteristic Configuration descriptors to be notified about
> attribute changes. If the server doesn't support these descriptors,
> the client shall implement a polling mechanism to check for attribute
> value changes.
> ---
> TODO | 7 ------
> src/attrib-server.c | 60 ++++----------------------------------------------
> 2 files changed, 5 insertions(+), 62 deletions(-)
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* [PATCH] TODO: Implement Server Characteristic Configuration
From: Claudio Takahasi @ 2010-10-13 16:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1286460773-25436-1-git-send-email-claudio.takahasi@openbossa.org>
---
TODO | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 7939d9d..0a7b482 100644
--- a/TODO
+++ b/TODO
@@ -78,6 +78,14 @@ ATT/GATT
Priority: Low
Complexity: C1
+- Implement Server characteristic Configuration support in the attribute
+ server to manage characteristic value broadcasting. There is a single
+ instance of the Server Characteristic Configuration for all clients.
+ See Volume 3, Part G, section 3.3.3.4 for more information.
+
+ Priority: Low
+ Complexity: C1
+
- Long reads/writes don't work (consisting of multiple request packets)
Priority: Low
--
1.7.3.1
^ permalink raw reply related
* [PATCH 2/2] TODO: Implement Client Characteristic Configuration
From: Claudio Takahasi @ 2010-10-13 16:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1286459639-25194-2-git-send-email-claudio.takahasi@openbossa.org>
---
TODO | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 3e62518..7939d9d 100644
--- a/TODO
+++ b/TODO
@@ -89,3 +89,12 @@ ATT/GATT
Priority: Low
Complexity: C2
+
+- Implement Client Characteristic Configuration support in the attribute
+ server to manage indications and notications. This is a per client attribute
+ to control how the client wants to receive reports of changes in a given
+ characteristic value.
+ See Volume 3, Part G, section 3.3.3.3 for more information
+
+ Priority: Low
+ Complexity: C2
--
1.7.3.1
^ permalink raw reply related
* [PATCH 1/2] Disable automatic notification/indication in the attribute server
From: Claudio Takahasi @ 2010-10-13 16:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1286459639-25194-1-git-send-email-claudio.takahasi@openbossa.org>
Attribute server shall not send automatic indication/notification
messages if the client didn't request them. Client shall use Client
/Server Characteristic Configuration descriptors to be notified about
attribute changes. If the server doesn't support these descriptors,
the client shall implement a polling mechanism to check for attribute
value changes.
---
TODO | 7 ------
src/attrib-server.c | 60 ++++----------------------------------------------
2 files changed, 5 insertions(+), 62 deletions(-)
diff --git a/TODO b/TODO
index 3885c78..3e62518 100644
--- a/TODO
+++ b/TODO
@@ -18,13 +18,6 @@ Background
ATT/GATT
========
-- Sample server shouldn't send any indications or notifications without
- the client requesting them
-
- Priority: Medium
- Complexity: C2
- Owner: Claudio Takahasi <claudio.takahasi@openbossa.org>
-
- Add ATT/GATT parsing to hcidump
Priority: Medium
diff --git a/src/attrib-server.c b/src/attrib-server.c
index 666b5fa..1fc1c18 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -590,54 +590,6 @@ static void confirm_event(GIOChannel *io, void *user_data)
return;
}
-static gboolean send_notification(gpointer user_data)
-{
- uint8_t pdu[ATT_MAX_MTU];
- guint handle = GPOINTER_TO_UINT(user_data);
- struct attribute *a;
- GSList *l;
- uint16_t length;
-
- l = g_slist_find_custom(database, GUINT_TO_POINTER(handle), handle_cmp);
- if (!l)
- return FALSE;
-
- a = l->data;
-
- for (l = clients; l; l = l->next) {
- struct gatt_channel *channel = l->data;
-
- length = enc_notification(a, pdu, channel->mtu);
- g_attrib_send(channel->attrib, pdu[0], pdu, length, NULL, NULL, NULL);
- }
-
- return FALSE;
-}
-
-static gboolean send_indication(gpointer user_data)
-{
- uint8_t pdu[ATT_MAX_MTU];
- guint handle = GPOINTER_TO_UINT(user_data);
- struct attribute *a;
- GSList *l;
- uint16_t length;
-
- l = g_slist_find_custom(database, GUINT_TO_POINTER(handle), handle_cmp);
- if (!l)
- return FALSE;
-
- a = l->data;
-
- for (l = clients; l; l = l->next) {
- struct gatt_channel *channel = l->data;
-
- length = enc_indication(a, pdu, channel->mtu);
- g_attrib_send(channel->attrib, pdu[0], pdu, length, NULL, NULL, NULL);
- }
-
- return FALSE;
-}
-
int attrib_server_init(void)
{
GError *gerr = NULL;
@@ -757,14 +709,12 @@ int attrib_db_update(uint16_t handle, uuid_t *uuid, const uint8_t *value,
memcpy(a->data, value, len);
/*
- * Characteristic configuration descriptor is not being used yet.
- * If the attribute changes, all connected clients will be notified.
- * For testing purposes, we send a Notification and a Indication for
- * each update.
+ * <<Client/Server Characteristic Configuration>> descriptors are
+ * not supported yet. If a given attribute changes, the attribute
+ * server shall report the new values using the mechanism selected
+ * by the client. Notification/Indication shall not be automatically
+ * sent if the client didn't request them.
*/
- g_idle_add(send_notification, GUINT_TO_POINTER(h));
-
- g_idle_add(send_indication, GUINT_TO_POINTER(h));
return 0;
}
--
1.7.3.1
^ permalink raw reply related
* Enabling SCO mode
From: Greg Mercurio @ 2010-10-13 15:45 UTC (permalink / raw)
To: linux-bluetooth
I am new to Bluez and have a question about sco audio. I am using Bluez version 4.47 in an Android environment.
The Bluetooth chip I’m using is initialized to use the PCM interface for sco audio data. So, the chip should be ready to transmit the sco audio when enabled.
>From what I can tell by looking at the Android code, the Bluetooth Handsfree Java application in initiates a sco connection by opening a sco socket connection with the stack.
I assume that opening the sco connection will send vendor independent HCI commands to the Bluetooth chip to put it into sco mode. I don’t see in the code where this is done.
Can someone confirm my assumptions and point me to the place in the code where enabling the sco commands are sent to the chip?
Thanks,
Greg
^ permalink raw reply
* Re: [PATCH] Fix problem with operator name length
From: Johan Hedberg @ 2010-10-13 15:09 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: Lukasz Pawlik, linux-bluetooth@vger.kernel.org
In-Reply-To: <1286981571.2142.5.camel@dp-x301>
Hi Dmitriy,
First of all, don't top-post on this list.
On Wed, Oct 13, 2010, Dmitriy Paliy wrote:
> At the moment it is received in ascii from csd since not all car kits
> can handle utf8.
Ok, in that case it should be safe. I went ahead and and pushed the
patch along with a clarification in the commit message about this
guarantee that the csd API gives.
Johan
^ permalink raw reply
* Re: [PATCH] Fix problem with operator name length
From: Dmitriy Paliy @ 2010-10-13 14:52 UTC (permalink / raw)
To: ext Johan Hedberg, Lukasz Pawlik; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20101013141921.GB4828@jh-x301>
Hi,
At the moment it is received in ascii from csd since not all car kits
can handle utf8.
Br,
Dmitriy
On Wed, 2010-10-13 at 16:19 +0200, ext Johan Hedberg wrote:
> Hi Lukasz,
>
> On Wed, Oct 13, 2010, Lukasz Pawlik wrote:
> > - net.operator_name = g_strdup(name);
> > -
> > + net.operator_name = g_strndup(name, 16);
>
> Is it possible that the the format of the name would be such that byte
> boundaries are not always the same as character boundaries (e.g. UTF-8)?
> If so, using g_strndup sounds dangerous since it assumes one byte per
> character.
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Some code cleanup in hdp
From: Johan Hedberg @ 2010-10-13 14:43 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1286978044-16484-1-git-send-email-santoscadenas@gmail.com>
Hi Jose,
On Wed, Oct 13, 2010, Jose Antonio Santos Cadenas wrote:
> ---
> health/hdp.c | 38 ++++++++++++++++++++++----------------
> health/hdp_util.c | 29 ++++++++++++++++++-----------
> 2 files changed, 40 insertions(+), 27 deletions(-)
Thanks. Pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Fix X-IRMC-CALL-DATETIME format
From: Johan Hedberg @ 2010-10-13 14:25 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1286975756-13134-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Wed, Oct 13, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> Use the format suggested in the spec:
>
> "For instance, a call that was missed on March 20th, 2005 at 10 am would
> be stamped: X-IRMC-CALL-DATETIME;MISSED:20050320T100000"
> ---
> plugins/phonebook-tracker.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Adjust mce_bt_set flag to gboolean type values
From: Johan Hedberg @ 2010-10-13 14:24 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1286975300-2832-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Wed, Oct 13, 2010, Rafal Michalski wrote:
> - mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH);
> + mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH ?
> + TRUE : FALSE;
Ok, that's basically a coding style fix.
> - mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH;
> + mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH ? TRUE : FALSE;
And that's a clear bug fix (since there's no guarantee that the binary
and results in the value 1 or TRUE).
In principle I'd prefer having coding style patches separate from real
bug fixes (even for trivial changes), but since these are related I've
let it go for now and pushed the patch upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Fix problem with operator name length
From: Johan Hedberg @ 2010-10-13 14:19 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1286974170-12282-1-git-send-email-lucas.pawlik@gmail.com>
Hi Lukasz,
On Wed, Oct 13, 2010, Lukasz Pawlik wrote:
> - net.operator_name = g_strdup(name);
> -
> + net.operator_name = g_strndup(name, 16);
Is it possible that the the format of the name would be such that byte
boundaries are not always the same as character boundaries (e.g. UTF-8)?
If so, using g_strndup sounds dangerous since it assumes one byte per
character.
Johan
^ permalink raw reply
* Re: [PATCH] Fix telephony-maemo6: call notification with call on hold
From: Johan Hedberg @ 2010-10-13 14:16 UTC (permalink / raw)
To: Daniel Örstadius; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimb82Ykv9fg2Oew4YoN1767e5_NX4Tid+3wHOzE@mail.gmail.com>
Hi Daniel,
On Wed, Oct 13, 2010, Daniel Örstadius wrote:
> BlueZ sends +CLIP and RING when there is an incoming call and no
> currently active call. If there is an active call it sends AT+CCWA
> (call waiting notification).
>
> Modification to send AT+CCWA instead of +CLIP and RING also when
> there is a call on hold (the incoming call goes into the waiting
> state).
> ---
> audio/telephony-maemo6.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] Some code cleanup in hdp
From: Jose Antonio Santos Cadenas @ 2010-10-13 13:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
---
health/hdp.c | 38 ++++++++++++++++++++++----------------
health/hdp_util.c | 29 ++++++++++++++++++-----------
2 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index 4a6da78..954b6d6 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -305,11 +305,12 @@ static DBusMessage *manager_create_application(DBusConnection *conn,
const char *name;
DBusMessageIter iter;
GError *err = NULL;
- DBusMessage *reply;
dbus_message_iter_init(msg, &iter);
app = hdp_get_app_config(&iter, &err);
if (err) {
+ DBusMessage *reply;
+
reply = g_dbus_create_error(msg,
ERROR_INTERFACE ".InvalidArguments",
"Invalid arguments: %s", err->message);
@@ -439,12 +440,13 @@ static void abort_mdl_cb(GError *err, gpointer data)
static void hdp_mdl_reconn_cb(struct mcap_mdl *mdl, GError *err, gpointer data)
{
struct hdp_tmp_dc_data *dc_data = data;
- struct hdp_channel *chan = dc_data->hdp_chann;
- GError *gerr = NULL;
DBusMessage *reply;
int fd;
if (err) {
+ struct hdp_channel *chan = dc_data->hdp_chann;
+ GError *gerr = NULL;
+
error("%s", err->message);
reply = g_dbus_create_error(dc_data->msg,
ERROR_INTERFACE ".HealthError",
@@ -633,12 +635,13 @@ static void health_channel_destroy(void *data)
{
struct hdp_channel *hdp_chan = data;
struct hdp_device *dev = hdp_chan->dev;
- char *empty_path;
DBG("Destroy Health Channel %s", hdp_chan->path);
dev->channels = g_slist_remove(dev->channels, hdp_chan);
if (hdp_chan == dev->fr) {
+ char *empty_path;
+
dev->fr = NULL;
empty_path = "";
emit_property_changed(dev->conn, device_get_path(dev->dev),
@@ -754,8 +757,6 @@ static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void *data)
{
struct hdp_device *dev = data;
struct hdp_channel *chan;
- GIOChannel *io_chan;
- int fd;
DBG("hdp_mcap_mdl_connected_cb");
if (!dev->ndc)
@@ -769,16 +770,19 @@ static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void *data)
dev->channels = g_slist_prepend(dev->channels, chan);
if (chan->mdep == HDP_MDEP_ECHO) {
+ GIOChannel *io;
+ int fd;
+
fd = mcap_mdl_get_fd(chan->mdl);
if (fd < 0)
return;
chan->echo_done = FALSE;
- io_chan = g_io_channel_unix_new(fd);
- chan->wid = g_io_add_watch(io_chan,
+ io = g_io_channel_unix_new(fd);
+ chan->wid = g_io_add_watch(io,
G_IO_ERR | G_IO_HUP | G_IO_NVAL | G_IO_IN,
serve_echo, chan);
- g_io_channel_unref(io_chan);
+ g_io_channel_unref(io);
return;
}
@@ -859,8 +863,6 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
{
struct hdp_device *dev = data;
struct hdp_application *app;
- struct hdp_channel *chan;
- char *path;
GSList *l;
DBG("Data channel request");
@@ -922,7 +924,9 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
l = g_slist_find_custom(dev->channels, &mdlid, cmp_chan_mdlid);
if (l) {
- chan = l->data;
+ struct hdp_channel *chan = l->data;
+ char *path;
+
path = g_strdup(chan->path);
g_dbus_unregister_interface(dev->conn, path, HEALTH_CHANNEL);
g_free(path);
@@ -981,16 +985,17 @@ gboolean hdp_set_mcl_cb(struct hdp_device *device, GError **err)
static void mcl_connected(struct mcap_mcl *mcl, gpointer data)
{
- struct hdp_adapter *hdp_adapter = data;
struct hdp_device *hdp_device;
- struct btd_device *device;
bdaddr_t addr;
- char str[18];
GSList *l;
mcap_mcl_get_addr(mcl, &addr);
l = g_slist_find_custom(devices, &addr, cmp_dev_addr);
if (!l) {
+ struct hdp_adapter *hdp_adapter = data;
+ struct btd_device *device;
+ char str[18];
+
ba2str(&addr, str);
device = adapter_get_device(connection,
hdp_adapter->btd_adapter, str);
@@ -1088,7 +1093,6 @@ static void check_devices_mcl()
{
struct hdp_device *dev;
GSList *l, *to_delete = NULL;
- const char *path;
for (l = devices; l; l = l->next) {
dev = l->data;
@@ -1101,6 +1105,8 @@ static void check_devices_mcl()
}
for (l = to_delete; l; l = l->next) {
+ const char *path;
+
path = device_get_path(dev->dev);
g_dbus_unregister_interface(dev->conn, path, HEALTH_DEVICE);
}
diff --git a/health/hdp_util.c b/health/hdp_util.c
index ef76b15..c5dfb01 100644
--- a/health/hdp_util.c
+++ b/health/hdp_util.c
@@ -141,12 +141,14 @@ static gboolean parse_data_type(DBusMessageIter *iter, gpointer data,
GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *value, variant;
+ DBusMessageIter *value;
int ctype;
ctype = dbus_message_iter_get_arg_type(iter);
value = iter;
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -167,13 +169,14 @@ static gboolean parse_data_type(DBusMessageIter *iter, gpointer data,
static gboolean parse_role(DBusMessageIter *iter, gpointer data, GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter value;
DBusMessageIter *string;
int ctype;
const char *role;
ctype = dbus_message_iter_get_arg_type(iter);
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter value;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &value);
ctype = dbus_message_iter_get_arg_type(&value);
@@ -206,12 +209,14 @@ static gboolean parse_role(DBusMessageIter *iter, gpointer data, GError **err)
static gboolean parse_desc(DBusMessageIter *iter, gpointer data, GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *string, variant;
+ DBusMessageIter *string;
int ctype;
const char *desc;
ctype = dbus_message_iter_get_arg_type(iter);
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -234,12 +239,14 @@ static gboolean parse_chan_type(DBusMessageIter *iter, gpointer data,
GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *value, variant;
+ DBusMessageIter *value;
int ctype;
ctype = dbus_message_iter_get_arg_type(iter);
value = iter;
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -294,11 +301,11 @@ fail:
static gboolean is_app_role(GSList *app_list, HdpRole role)
{
- struct hdp_application *app;
GSList *l;
for (l = app_list; l; l = l->next) {
- app = l->data;
+ struct hdp_application *app = l->data;
+
if (app->role == role)
return TRUE;
}
@@ -732,7 +739,7 @@ static gboolean check_role(uint8_t rec_role, uint8_t app_role)
static gboolean get_mdep_from_rec(const sdp_record_t *rec, uint8_t role,
uint16_t d_type, uint8_t *mdep, char **desc)
{
- sdp_data_t *list, *feat, *data_type, *mdepid, *role_t, *desc_t;
+ sdp_data_t *list, *feat;
if (!desc && !mdep)
return TRUE;
@@ -744,6 +751,8 @@ static gboolean get_mdep_from_rec(const sdp_record_t *rec, uint8_t role,
return FALSE;
for (feat = list->val.dataseq; feat; feat = feat->next) {
+ sdp_data_t *data_type, *mdepid, *role_t, *desc_t;
+
if (feat->dtd != SDP_SEQ8 && feat->dtd != SDP_SEQ16 &&
feat->dtd != SDP_SEQ32)
continue;
@@ -931,10 +940,9 @@ static gboolean hdp_get_add_prot_desc_list(const sdp_record_t *rec,
static gboolean get_ccpsm(sdp_list_t *recs, uint16_t *ccpsm)
{
sdp_list_t *l;
- sdp_record_t *rec;
for (l = recs; l; l = l->next) {
- rec = l->data;
+ sdp_record_t *rec = l->data;
if (hdp_get_prot_desc_list(rec, ccpsm, NULL))
return TRUE;
@@ -946,10 +954,9 @@ static gboolean get_ccpsm(sdp_list_t *recs, uint16_t *ccpsm)
static gboolean get_dcpsm(sdp_list_t *recs, uint16_t *dcpsm)
{
sdp_list_t *l;
- sdp_record_t *rec;
for (l = recs; l; l = l->next) {
- rec = l->data;
+ sdp_record_t *rec = l->data;
if (hdp_get_add_prot_desc_list(rec, dcpsm))
return TRUE;
--
1.7.1
^ permalink raw reply related
* [PATCH] Fix X-IRMC-CALL-DATETIME format
From: Luiz Augusto von Dentz @ 2010-10-13 13:15 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Use the format suggested in the spec:
"For instance, a call that was missed on March 20th, 2005 at 10 am would
be stamped: X-IRMC-CALL-DATETIME;MISSED:20050320T100000"
---
plugins/phonebook-tracker.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index d0cea2e..39e4c81 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -705,7 +705,7 @@ static char *iso8601_utc_to_localtime(const char *datetime)
memset(&tm, 0, sizeof(tm));
- nr = sscanf(datetime, "%04u-%02u-%02uT%02u:%02u:%02u%c",
+ nr = sscanf(datetime, "%04u%02u%02uT%02u%02u%02u%c",
&tm.tm_year, &tm.tm_mon, &tm.tm_mday,
&tm.tm_hour, &tm.tm_min, &tm.tm_sec,
&tz);
@@ -726,7 +726,7 @@ static char *iso8601_utc_to_localtime(const char *datetime)
local = localtime(&time);
- strftime(localdate, sizeof(localdate), "%Y-%m-%dT%H:%M:%S", local);
+ strftime(localdate, sizeof(localdate), "%Y%m%dT%H%M%S", local);
return g_strdup(localdate);
}
--
1.7.1
^ permalink raw reply related
* [PATCH] Adjust mce_bt_set flag to gboolean type values
From: Rafal Michalski @ 2010-10-13 13:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
This patch makes assignment to mce_bt_set flag more readable and makes
sure that it takes only TRUE or FALSE value from gboolean type.
---
plugins/maemo6.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/plugins/maemo6.c b/plugins/maemo6.c
index c396db0..0a1e551 100644
--- a/plugins/maemo6.c
+++ b/plugins/maemo6.c
@@ -71,7 +71,8 @@ static gboolean mce_signal_callback(DBusConnection *connection,
/* set the adapter according to the mce signal
and remember the value */
- mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH);
+ mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH ?
+ TRUE : FALSE;
if (mce_bt_set)
btd_adapter_switch_online(adapter);
@@ -111,7 +112,7 @@ static void read_radio_states_cb(DBusPendingCall *call, void *user_data)
DBG("radio_states: %d", radio_states);
- mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH;
+ mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH ? TRUE : FALSE;
/* check if the adapter has not completed the initial power
* cycle, if so delay action to mce_notify_powered */
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] gdbus: fix not handling bus disconnects
From: Marcel Holtmann @ 2010-10-13 12:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1286971606-11790-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
> We where not dispatching data when a bus disconnects which cause
> Disconnected signal to not be processed and thus causing the process to
> either not exit or to not trigger callbacks registered with
> g_dbus_set_disconnect_function.
>
> To fix this now we always schedule a dispatch which will make sure data
> still not processed will make its way to the proper handlers even if
> disconnected.
this looks fine to me. Went ahead and applied to all repositories.
Regards
Marcel
^ permalink raw reply
* [PATCH] Fix problem with operator name length
From: Lukasz Pawlik @ 2010-10-13 12:49 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
To follow the HFP specification we must ensure that network operator name
will have at maximum 16 characters. In current implementation we do not
check this constraint. This patch fix this. Now operator name with more
than 16 characters will be truncated to 16 characters.
---
audio/telephony-maemo6.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 1aac034..bbd2d2f 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -1498,8 +1498,7 @@ static void update_operator_name(const char *name)
return;
g_free(net.operator_name);
- net.operator_name = g_strdup(name);
-
+ net.operator_name = g_strndup(name, 16);
DBG("telephony-maemo6: operator name updated: %s", name);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Fix telephony-maemo6: call notification with call on hold
From: Daniel Örstadius @ 2010-10-13 12:38 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Fix-telephony-maemo6-call-notification-with-call-on.patch --]
[-- Type: text/x-patch, Size: 1205 bytes --]
From fc43271937812cf668b450dc07f77f5688ef6c87 Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Tue, 12 Oct 2010 14:09:55 +0300
Subject: [PATCH] Fix telephony-maemo6: call notification with call on hold
BlueZ sends +CLIP and RING when there is an incoming call and no
currently active call. If there is an active call it sends AT+CCWA
(call waiting notification).
Modification to send AT+CCWA instead of +CLIP and RING also when
there is a call on hold (the incoming call goes into the waiting
state).
---
audio/telephony-maemo6.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 05ff332..f0273ee 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -910,7 +910,8 @@ static void handle_incoming_call(DBusMessage *msg)
telephony_update_indicator(maemo_indicators, "callsetup",
EV_CALLSETUP_INCOMING);
- if (find_call_with_status(CSD_CALL_STATUS_ACTIVE))
+ if (find_call_with_status(CSD_CALL_STATUS_ACTIVE) ||
+ find_call_with_status(CSD_CALL_STATUS_HOLD))
telephony_call_waiting_ind(call->number,
number_type(call->number));
else
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] Fix suspend stream on opening if no data
From: Johan Hedberg @ 2010-10-13 12:30 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1286972456-6168-2-git-send-email-dmitriy.paliy@nokia.com>
Hi Dmitriy,
On Wed, Oct 13, 2010, Dmitriy Paliy wrote:
> Fix write to stream and suspend it immidiately if there is no data
> available.
> ---
> src/obex.c | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
Looks good. The patch has been pushed upstream. Do pay attention to
whitespace issues in the future though. I got this when applying it:
Applying: Fix suspend stream on opening if no data
/home/jh/src/obexd/.git/rebase-apply/patch:18: trailing whitespace.
warning: 1 line applied after fixing whitespace errors.
This came from the empty line with two tabs after the AddHeader call:
> OBEX_ObjectAddHeader (obex, obj, OBEX_HDR_BODY,
> hd, 0, OBEX_FL_STREAM_START);
> +
Johan
^ permalink raw reply
* Re: [PATCH] Fix suspend stream on opening if no data
From: Bastien Nocera @ 2010-10-13 12:24 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1286972456-6168-2-git-send-email-dmitriy.paliy@nokia.com>
On Wed, 2010-10-13 at 15:20 +0300, Dmitriy Paliy wrote:
> + /* Try to write to stream and suspend the stream
> immidiately
Should be immediately (and in the log message as well)
^ permalink raw reply
* [PATCH] Fix suspend stream on opening if no data
From: Dmitriy Paliy @ 2010-10-13 12:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Dmitriy Paliy
In-Reply-To: <1286972456-6168-1-git-send-email-dmitriy.paliy@nokia.com>
Fix write to stream and suspend it immidiately if there is no data
available.
---
src/obex.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/src/obex.c b/src/obex.c
index c7d0753..71bcba8 100644
--- a/src/obex.c
+++ b/src/obex.c
@@ -813,10 +813,22 @@ static void cmd_get(struct obex_session *os, obex_t *obex, obex_object_t *obj)
os->obj = obj;
os->driver->set_io_watch(os->object, handle_async_io, os);
return;
- } else
+ } else {
/* Standard data stream */
OBEX_ObjectAddHeader (obex, obj, OBEX_HDR_BODY,
hd, 0, OBEX_FL_STREAM_START);
+
+ /* Try to write to stream and suspend the stream immidiately
+ * if no data available to send. */
+ err = obex_write_stream(os, obex, obj);
+ if (err == -EAGAIN) {
+ OBEX_SuspendRequest(obex, obj);
+ os->obj = obj;
+ os->driver->set_io_watch(os->object, handle_async_io,
+ os);
+ return;
+ }
+ }
done:
os_set_response(obj, err);
--
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