* [PATCH BlueZ v1 03/10] gatt: Add read Appearance characteristic
From: Claudio Takahasi @ 2012-08-16 20:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345147991-31320-1-git-send-email-claudio.takahasi@openbossa.org>
This patch registers the ATTIO callbacks, and triggers the Appearance
characteristic read by UUID when the ATT connection is established (if
appearance value is not found in the storage).
---
profiles/gatt/gas.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/profiles/gatt/gas.c b/profiles/gatt/gas.c
index d13eadc..2fb12ce 100644
--- a/profiles/gatt/gas.c
+++ b/profiles/gatt/gas.c
@@ -29,8 +29,10 @@
#include "adapter.h"
#include "device.h"
+#include "storage.h"
#include "att.h"
#include "gattrib.h"
+#include "attio.h"
#include "gatt.h"
#include "log.h"
#include "gas.h"
@@ -40,12 +42,17 @@ struct gas {
struct btd_device *device;
struct att_range gap; /* GAP Primary service range */
struct att_range gatt; /* GATT Primary service range */
+ GAttrib *attrib;
+ guint attioid;
};
static GSList *devices = NULL;
static void gas_free(struct gas *gas)
{
+ if (gas->attioid)
+ btd_device_remove_attio_callback(gas->device, gas->attioid);
+
btd_device_unref(gas->device);
g_free(gas);
}
@@ -58,6 +65,70 @@ static gint cmp_device(gconstpointer a, gconstpointer b)
return (gas->device == device ? 0 : -1);
}
+static void gap_appearance_cb(guint8 status, const guint8 *pdu, guint16 plen,
+ gpointer user_data)
+{
+ struct att_data_list *list = NULL;
+ uint16_t app;
+ uint8_t *atval;
+
+ if (status != 0) {
+ error("Read characteristics by UUID failed: %s",
+ att_ecode2str(status));
+ return;
+ }
+
+ list = dec_read_by_type_resp(pdu, plen);
+ if (list == NULL)
+ return;
+
+ if (list->len != 4) {
+ error("GAP Appearance value: invalid data");
+ goto done;
+ }
+
+ atval = list->data[0] + 2; /* skip handle value */
+ app = att_get_u16(atval);
+
+ DBG("GAP Appearance: 0x%04x", app);
+
+done:
+ att_data_list_free(list);
+}
+
+static void attio_connected_cb(GAttrib *attrib, gpointer user_data)
+{
+ struct gas *gas = user_data;
+ bdaddr_t src, dst;
+ uint16_t app;
+ uint8_t type;
+
+ gas->attrib = g_attrib_ref(attrib);
+
+ adapter_get_address(device_get_adapter(gas->device), &src);
+ device_get_address(gas->device, &dst, &type);
+
+ if (read_remote_appearance(&src, &dst, type, &app) < 0) {
+ bt_uuid_t uuid;
+
+ bt_uuid16_create(&uuid, GATT_CHARAC_APPEARANCE);
+
+ gatt_read_char_by_uuid(gas->attrib, gas->gap.start,
+ gas->gap.end, &uuid,
+ gap_appearance_cb, gas);
+ }
+
+ /* TODO: Read other GAP characteristics - See Core spec page 1739 */
+}
+
+static void attio_disconnected_cb(gpointer user_data)
+{
+ struct gas *gas = user_data;
+
+ g_attrib_unref(gas->attrib);
+ gas->attrib = NULL;
+}
+
int gas_register(struct btd_device *device, struct att_range *gap,
struct att_range *gatt)
{
@@ -73,6 +144,10 @@ int gas_register(struct btd_device *device, struct att_range *gap,
devices = g_slist_append(devices, gas);
+ gas->attioid = btd_device_add_attio_callback(device,
+ attio_connected_cb,
+ attio_disconnected_cb, gas);
+
return 0;
}
--
1.7.8.6
^ permalink raw reply related
* [PATCH BlueZ v1 02/10] gatt: Add GAP/GATT device registration
From: Claudio Takahasi @ 2012-08-16 20:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345147991-31320-1-git-send-email-claudio.takahasi@openbossa.org>
This patch adds GAP/GATT device driver probe function and the skeleton
of the register GAP/GATT device function.
---
Makefile.am | 3 +-
profiles/gatt/gas.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++
profiles/gatt/gas.h | 25 +++++++++++++
profiles/gatt/manager.c | 29 ++++++++++++++-
4 files changed, 146 insertions(+), 2 deletions(-)
create mode 100644 profiles/gatt/gas.c
create mode 100644 profiles/gatt/gas.h
diff --git a/Makefile.am b/Makefile.am
index 6af33cb..4977a05 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -240,7 +240,8 @@ builtin_sources += profiles/thermometer/main.c \
profiles/deviceinfo/deviceinfo.h \
profiles/deviceinfo/deviceinfo.c \
profiles/gatt/main.c profiles/gatt/manager.h \
- profiles/gatt/manager.c
+ profiles/gatt/manager.c profiles/gatt/gas.h \
+ profiles/gatt/gas.c
endif
builtin_modules += formfactor
diff --git a/profiles/gatt/gas.c b/profiles/gatt/gas.c
new file mode 100644
index 0000000..d13eadc
--- /dev/null
+++ b/profiles/gatt/gas.c
@@ -0,0 +1,91 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2012 Instituto Nokia de Tecnologia - INdT
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <glib.h>
+#include <bluetooth/uuid.h>
+
+#include "adapter.h"
+#include "device.h"
+#include "att.h"
+#include "gattrib.h"
+#include "gatt.h"
+#include "log.h"
+#include "gas.h"
+
+/* Generic Attribute/Access Service */
+struct gas {
+ struct btd_device *device;
+ struct att_range gap; /* GAP Primary service range */
+ struct att_range gatt; /* GATT Primary service range */
+};
+
+static GSList *devices = NULL;
+
+static void gas_free(struct gas *gas)
+{
+ btd_device_unref(gas->device);
+ g_free(gas);
+}
+
+static gint cmp_device(gconstpointer a, gconstpointer b)
+{
+ const struct gas *gas = a;
+ const struct btd_device *device = b;
+
+ return (gas->device == device ? 0 : -1);
+}
+
+int gas_register(struct btd_device *device, struct att_range *gap,
+ struct att_range *gatt)
+{
+ struct gas *gas;
+
+ gas = g_new0(struct gas, 1);
+ gas->gap.start = gap->start;
+ gas->gap.end = gap->end;
+ gas->gatt.start = gatt->start;
+ gas->gatt.end = gatt->end;
+
+ gas->device = btd_device_ref(device);
+
+ devices = g_slist_append(devices, gas);
+
+ return 0;
+}
+
+void gas_unregister(struct btd_device *device)
+{
+ struct gas *gas;
+ GSList *l;
+
+ l = g_slist_find_custom(devices, device, cmp_device);
+ if (l == NULL)
+ return;
+
+ gas = l->data;
+ devices = g_slist_remove(devices, gas);
+ gas_free(gas);
+}
diff --git a/profiles/gatt/gas.h b/profiles/gatt/gas.h
new file mode 100644
index 0000000..34853c7
--- /dev/null
+++ b/profiles/gatt/gas.h
@@ -0,0 +1,25 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2012 Instituto Nokia de Tecnologia - INdT
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+int gas_register(struct btd_device *device, struct att_range *gap,
+ struct att_range *gatt);
+void gas_unregister(struct btd_device *device);
diff --git a/profiles/gatt/manager.c b/profiles/gatt/manager.c
index ab98f86..a1fa756 100644
--- a/profiles/gatt/manager.c
+++ b/profiles/gatt/manager.c
@@ -26,15 +26,42 @@
#include "adapter.h"
#include "device.h"
+#include "att.h"
+#include "gattrib.h"
+#include "gatt.h"
+#include "gas.h"
#include "manager.h"
+static gint primary_uuid_cmp(gconstpointer a, gconstpointer b)
+{
+ const struct gatt_primary *prim = a;
+ const char *uuid = b;
+
+ return g_strcmp0(prim->uuid, uuid);
+}
+
static int gatt_driver_probe(struct btd_device *device, GSList *uuids)
{
- return 0;
+ GSList *primaries, *l;
+ struct gatt_primary *gap = NULL, *gatt = NULL;
+
+ primaries = btd_device_get_primaries(device);
+
+ l = g_slist_find_custom(primaries, GAP_UUID, primary_uuid_cmp);
+ if (l)
+ gap = l->data;
+
+ l = g_slist_find_custom(primaries, GATT_UUID, primary_uuid_cmp);
+ if (l)
+ gatt = l->data;
+
+ return gas_register(device, gap ? &gap->range : NULL,
+ gatt ? &gatt->range : NULL);
}
static void gatt_driver_remove(struct btd_device *device)
{
+ gas_unregister(device);
}
static struct btd_device_driver gatt_device_driver = {
--
1.7.8.6
^ permalink raw reply related
* [PATCH BlueZ v1 01/10] gatt: Add Generic Access/Attribute Profile plugin
From: Claudio Takahasi @ 2012-08-16 20:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345147991-31320-1-git-send-email-claudio.takahasi@openbossa.org>
Initial patch to create GATT based plugin to handle Generic Access,
and Generic Attribute Profile services. GAP characteristics discovery
will be moved from device.c to this new plugin.
---
Makefile.am | 7 ++++-
profiles/gatt/main.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
profiles/gatt/manager.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++
profiles/gatt/manager.h | 24 ++++++++++++++++++++
4 files changed, 136 insertions(+), 2 deletions(-)
create mode 100644 profiles/gatt/main.c
create mode 100644 profiles/gatt/manager.c
create mode 100644 profiles/gatt/manager.h
diff --git a/Makefile.am b/Makefile.am
index a74709d..6af33cb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -211,7 +211,8 @@ builtin_sources += profiles/health/hdp_main.c profiles/health/hdp_types.h \
endif
if GATTMODULES
-builtin_modules += thermometer alert time gatt_example proximity deviceinfo
+builtin_modules += thermometer alert time gatt_example proximity deviceinfo \
+ gatt
builtin_sources += profiles/thermometer/main.c \
profiles/thermometer/manager.h \
profiles/thermometer/manager.c \
@@ -237,7 +238,9 @@ builtin_sources += profiles/thermometer/main.c \
profiles/deviceinfo/manager.h \
profiles/deviceinfo/manager.c \
profiles/deviceinfo/deviceinfo.h \
- profiles/deviceinfo/deviceinfo.c
+ profiles/deviceinfo/deviceinfo.c \
+ profiles/gatt/main.c profiles/gatt/manager.h \
+ profiles/gatt/manager.c
endif
builtin_modules += formfactor
diff --git a/profiles/gatt/main.c b/profiles/gatt/main.c
new file mode 100644
index 0000000..efe92f5
--- /dev/null
+++ b/profiles/gatt/main.c
@@ -0,0 +1,52 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2012 Instituto Nokia de Tecnologia - INdT
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdint.h>
+#include <glib.h>
+#include <errno.h>
+
+#include "plugin.h"
+#include "manager.h"
+#include "hcid.h"
+#include "log.h"
+
+static int gatt_init(void)
+{
+ if (!main_opts.gatt_enabled) {
+ error("GATT can not start: EnableGatt is false");
+ return -ENOTSUP;
+ }
+
+ return gatt_manager_init();
+}
+
+static void gatt_exit(void)
+{
+ gatt_manager_exit();
+}
+
+BLUETOOTH_PLUGIN_DEFINE(gatt, VERSION, BLUETOOTH_PLUGIN_PRIORITY_DEFAULT,
+ gatt_init, gatt_exit)
diff --git a/profiles/gatt/manager.c b/profiles/gatt/manager.c
new file mode 100644
index 0000000..ab98f86
--- /dev/null
+++ b/profiles/gatt/manager.c
@@ -0,0 +1,55 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2012 Instituto Nokia de Tecnologia - INdT
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include <glib.h>
+#include <errno.h>
+#include <bluetooth/uuid.h>
+
+#include "adapter.h"
+#include "device.h"
+#include "manager.h"
+
+static int gatt_driver_probe(struct btd_device *device, GSList *uuids)
+{
+ return 0;
+}
+
+static void gatt_driver_remove(struct btd_device *device)
+{
+}
+
+static struct btd_device_driver gatt_device_driver = {
+ .name = "gap-gatt-driver",
+ .uuids = BTD_UUIDS(GAP_UUID, GATT_UUID),
+ .probe = gatt_driver_probe,
+ .remove = gatt_driver_remove
+};
+
+int gatt_manager_init(void)
+{
+ return btd_register_device_driver(&gatt_device_driver);
+}
+
+void gatt_manager_exit(void)
+{
+ btd_unregister_device_driver(&gatt_device_driver);
+}
diff --git a/profiles/gatt/manager.h b/profiles/gatt/manager.h
new file mode 100644
index 0000000..502fceb
--- /dev/null
+++ b/profiles/gatt/manager.h
@@ -0,0 +1,24 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2012 Instituto Nokia de Tecnologia - INdT
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+int gatt_manager_init(void);
+void gatt_manager_exit(void);
--
1.7.8.6
^ permalink raw reply related
* [PATCH BlueZ v1 00/10] GATT Plugin
From: Claudio Takahasi @ 2012-08-16 20:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <CAKT1EBfp+iJfRSodDfoqtDB4X90BNR1wEJh_zXvw0t6JvnaWuA@mail.gmail.com>
This patch series adds a new GATT based plugin for GAP and GATT service.
The objective is cleanup: moving some GATT related operations from the
device(core) to a GATT based plugin.
This first part is related to GAP appearance characteristic. A second
patch will be sent soon to manage Service Changed and GATT/ATT MTU.
Claudio Takahasi (10):
gatt: Add Generic Access/Attribute Profile plugin
gatt: Add GAP/GATT device registration
gatt: Add read Appearance characteristic
gatt: Add storing Appearance
core: Remove Appearance characteristic read
gatt: Emit PropertyChanged for Appearance
core: PropertyChanged signal for Icon/class
core: PropertyChanged signal for Icon/Appearance
gatt: Map Appearance value 0x0000 to "unknown"
gatt: Don't store Appearance if value is "unknown"
Makefile.am | 8 ++-
profiles/gatt/gas.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++
profiles/gatt/gas.h | 25 +++++++
profiles/gatt/main.c | 52 ++++++++++++++
profiles/gatt/manager.c | 82 +++++++++++++++++++++
profiles/gatt/manager.h | 24 ++++++
src/dbus-common.c | 2 +
src/device.c | 74 +++++--------------
src/device.h | 1 +
9 files changed, 390 insertions(+), 57 deletions(-)
create mode 100644 profiles/gatt/gas.c
create mode 100644 profiles/gatt/gas.h
create mode 100644 profiles/gatt/main.c
create mode 100644 profiles/gatt/manager.c
create mode 100644 profiles/gatt/manager.h
--
1.7.8.6
^ permalink raw reply
* Re: Moving bluetooth plugin to gstreamer
From: Joao Paulo Rechi Vita @ 2012-08-16 19:50 UTC (permalink / raw)
To: Tim-Philipp Müller
Cc: Discussion of the development of and with GStreamer,
linux-bluetooth, Thiago Sousa Santos
In-Reply-To: <1345136955.28588.5.camel@zingle>
On Thu, Aug 16, 2012 at 2:09 PM, Tim-Philipp Müller <t.i.m@zen.co.uk> wrote:
> On Thu, 2012-08-16 at 16:25 +0300, Luiz Augusto von Dentz wrote:
>
> Hi,
>
>> Since we now have a proper library for SBC codec
>> (http://git.kernel.org/?p=bluetooth/sbc.git;a=summary) and its patent
>> has expired June 2, 2010. (source:
>> http://en.wikipedia.org/wiki/SBC_(codec)), I wonder if it wouldn't be
>> a good idea to move the plugin to gstreamer tree?
>>
>> The plugin has the following elements:
>>
>> bluetooth: sbcenc: Bluetooth SBC encoder
>> bluetooth: sbcdec: Bluetooth SBC decoder
>> bluetooth: sbcparse: Bluetooth SBC parser
>> bluetooth: avdtpsink: Bluetooth AVDTP sink
>> bluetooth: a2dpsink: Bluetooth A2DP sink
>> bluetooth: rtpsbcpay: RTP packet payloader
>
> Sounds like a good idea to me.
>
> We'd probably add them to gst-plugins-bad first though, since that's
> where new plugins are usually added before they get moved to -good or
> elsewhere. And probably only to git master (ie. for the upcoming
> 0.11/1.0 API version).
>
> Would the idea be that you'd turn libsbc from noinst into a proper
> library, or would we just move that over into the plugin as well?
>
It will be a shared lib, also used by pulseaudio's bluetooth modules.
--
João Paulo Rechi Vita
Openbossa Labs - INdT
^ permalink raw reply
* Re: [PATCH v4 01/10] Battery: Add Battery Service Gatt Client
From: Johan Hedberg @ 2012-08-16 19:24 UTC (permalink / raw)
To: Chen Ganir; +Cc: linux-bluetooth
In-Reply-To: <502CEDA7.2040908@ti.com>
Hi Chen,
On Thu, Aug 16, 2012, Chen Ganir wrote:
> >>However, i fail to understand why the object manager prevents this
> >>from getting accepted - do you have a time estimation when the
> >>object manager should be active or available ?
> >
> >By the time of our next release (as per the content under the BlueZ 5
> >section in our TODO file).
>
> Is there anywhere some documentation or instructions how to adapt
> the API for the new object manager ? Is it backward compatible to
> what we have today ? Do we really hold back DBUS additions until we
> change the DBUS API ?
As an unrelated thing (but since I saw it in your commit messages too):
please spell D-Bus as D-Bus, not DBUS, DBus, or anything else in natural
written language. This keeps it consistent with the rest of our
documentation as well as how the D-Bus project itself spells the name.
Regarding the Object Manager interface the implementation details you'd
get from Lucas and Luiz who are working on it whereas the API spec is
available here:
http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager
> >>I prefer this way of putting the batteries below the device, since it
> >>is obvious which battery belongs to each device.
> >
> >I fully agree with this. It's not what I had an issue with. However, if
> >we really want to make this clear you could additionally have a "Device"
> >property for each battery object pointing back to the parent object.
> I can do that, if it helps. Although it is not necessary, since the
> object path for a battery already contains the device objec path in
> it :
> [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
> Adding a device object path as a property will be redundant.
Even though we do have such a hierarchical construction of the paths I
don't think we should encourage this kind of magic tricks in trying look
into actual values of object paths to infer their relation to each
other. However, since the battery object paths would be discovered
through the device object there might not be any need for such a
backwards reference.
> >>The other option i can think of is to have another interface
> >>registered on the device object path:
> >>
> >>Service org.bluez
> >>Interface org.bluez.Batteries
> >>Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX
> >>
> >>Methods dict GetProperties()
> >>
> >> Returns all properties for the interface. See the
> >> Properties section for the available properties.
> >>
> >>Signals ProperyChanged(string name, variant value)
> >>
> >> This signal indicates a changed value of the given
> >> property.
> >>
> >>Properties array{object} Batteries [readonly]
> >>
> >> List of device battery object paths that represents the available
> >>batteries on the remote devices.
> >>
> >>
> >>Service org.bluez
> >>Interface org.bluez.Battery
> >>Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
> >>
> >>
> >>Methods dict GetProperties()
> >>
> >> Returns all properties for the interface. See the
> >> Properties section for the available properties.
> >>
> >>Signals PropertyChanged(string name, variant value)
> >>
> >> This signal indicates a changed value of the given
> >> property.
> >>
> >>Properties byte Level [readonly]
> >>
> >> Battery level (0-100).
> >>
> >>Any other suggestion ?
> >
> >That would work, although both of these interfaces are rather
> >light-weight in that they only contain a single property which begs the
> >question whether this is a bit over-kill.
> I know. I believe so as well, but if you want to separate the
> interfaces, it is a must.
>
> >
> >Another option is to do away with the per-battery object somehow and
> >expose all batteries through a single interface. I'm not so sure that's
> >a good idea though since it could prevent future extensibility of the
> >API and doesn't reuse the common tools we have for object-like
> >abstractions (which a battery certainly is).
> If we do what you suggest, a battery name (namespace+descriptor)
> will be the property name, and the value should be the battery
> level. i'm not too comfortable with it, and it is different than
> what we used to do up until now.
>
> So where do we go from here ?
Some extra opinions/view points could help. Maybe Marcel or Luiz have
some preferences/ideas on how to do this.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ v1] gdbus: Fix compilation error if macro "error" is defined
From: Johan Hedberg @ 2012-08-16 19:01 UTC (permalink / raw)
To: Jaganath Kanakkassery; +Cc: linux-bluetooth
In-Reply-To: <1345121479-9797-1-git-send-email-jaganath.k@samsung.com>
Hi Jaganath,
On Thu, Aug 16, 2012, Jaganath Kanakkassery wrote:
> The variable "signature" used in error is not defined and "args" is now
> a struct instead of a string.
> ---
> v1 -> Made a note of the removal of variable "args" in the commit message
>
> gdbus/object.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Applied to bluez.git and obexd.git. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] adapter: fix call to get_key_info
From: Johan Hedberg @ 2012-08-16 19:00 UTC (permalink / raw)
To: Henrique Dante de Almeida; +Cc: linux-bluetooth
In-Reply-To: <1345140926-19076-1-git-send-email-hdante@profusion.mobi>
Hi Henrique,
On Thu, Aug 16, 2012, Henrique Dante de Almeida wrote:
> This complements commit 85128d40f4788acb0115f09c07b716e741444406 that
> changed the "linkkeys" file format. The call to get_key_info must
> include only the address string, instead of the new combined
> address#type text.
> ---
> src/adapter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied. Thanks.
Johan
^ permalink raw reply
* [PATCH] adapter: fix call to get_key_info
From: Henrique Dante de Almeida @ 2012-08-16 18:15 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Henrique Dante de Almeida
This complements commit 85128d40f4788acb0115f09c07b716e741444406 that
changed the "linkkeys" file format. The call to get_key_info must
include only the address string, instead of the new combined
address#type text.
---
src/adapter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/adapter.c b/src/adapter.c
index e6b5559..b642e37 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -1808,7 +1808,7 @@ static void create_stored_device_from_linkkeys(char *key, char *value,
if (sscanf(key, "%17s#%hhu", address, &bdaddr_type) < 2)
bdaddr_type = BDADDR_BREDR;
- info = get_key_info(key, value);
+ info = get_key_info(address, value);
if (info)
keys->keys = g_slist_append(keys->keys, info);
--
1.7.12.rc2.16.g034161a
^ permalink raw reply related
* Re: Moving bluetooth plugin to gstreamer
From: Tim-Philipp Müller @ 2012-08-16 17:09 UTC (permalink / raw)
To: Discussion of the development of and with GStreamer
Cc: linux-bluetooth, Thiago Sousa Santos
In-Reply-To: <CABBYNZJ16G7zOEm+AJwmb8SeEtRyGzfiKFf+QsK8NdQGUUGqDA@mail.gmail.com>
On Thu, 2012-08-16 at 16:25 +0300, Luiz Augusto von Dentz wrote:
Hi,
> Since we now have a proper library for SBC codec
> (http://git.kernel.org/?p=bluetooth/sbc.git;a=summary) and its patent
> has expired June 2, 2010. (source:
> http://en.wikipedia.org/wiki/SBC_(codec)), I wonder if it wouldn't be
> a good idea to move the plugin to gstreamer tree?
>
> The plugin has the following elements:
>
> bluetooth: sbcenc: Bluetooth SBC encoder
> bluetooth: sbcdec: Bluetooth SBC decoder
> bluetooth: sbcparse: Bluetooth SBC parser
> bluetooth: avdtpsink: Bluetooth AVDTP sink
> bluetooth: a2dpsink: Bluetooth A2DP sink
> bluetooth: rtpsbcpay: RTP packet payloader
Sounds like a good idea to me.
We'd probably add them to gst-plugins-bad first though, since that's
where new plugins are usually added before they get moved to -good or
elsewhere. And probably only to git master (ie. for the upcoming
0.11/1.0 API version).
Would the idea be that you'd turn libsbc from noinst into a proper
library, or would we just move that over into the plugin as well?
Cheers
- Tim
^ permalink raw reply
* Re: Bluez 4.101
From: Anderson Lizardo @ 2012-08-16 15:57 UTC (permalink / raw)
To: John Tobias; +Cc: Chan-yeol Park, linux-bluetooth
In-Reply-To: <CACUGKYMohmq0FDXk2DpmZfF_sPk_dfL7NEgN+jr9k+65D_r02A@mail.gmail.com>
On Thu, Aug 16, 2012 at 11:38 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Anderson,
>
> Thanks for the info.
> May I know the difference between bluetooth.git and bluetooth-next.git repo?.
I may be wrong, but I think it is like this:
bluetooth-next.git contains what is going to the next kernel release
cycle. E.g. if we are on 3.6-rc1, what is currently on bluetooth-next
will probably enter upstream on 3.7. It may be less stable than
bluetooth.git.
bluetooth.git is for the current release cycle (i.e., will enter on 3.6).
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: Bluez 4.101
From: John Tobias @ 2012-08-16 15:38 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Chan-yeol Park, linux-bluetooth
In-Reply-To: <CAJdJm_PoC6CqojaroHPXy6sf-Sg+uS_DJZzm38Re6LDbUBmLHg@mail.gmail.com>
Hi Anderson,
Thanks for the info.
May I know the difference between bluetooth.git and bluetooth-next.git repo?.
Thanks
On Thu, Aug 16, 2012 at 3:57 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi John,
>
> On Wed, Aug 15, 2012 at 10:54 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Let me take it back. I used the kernel from ubuntu 12.04.
>
> You need at least 3.4.0 to use latest BlueZ (although the latest
> kernel version is always recommended for development). Ubuntu 12.04
> has 3.2.0.
>
> Best Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
^ permalink raw reply
* Moving bluetooth plugin to gstreamer
From: Luiz Augusto von Dentz @ 2012-08-16 13:25 UTC (permalink / raw)
To: gstreamer-devel; +Cc: linux-bluetooth, Thiago Sousa Santos
Hi,
Since we now have a proper library for SBC codec
(http://git.kernel.org/?p=bluetooth/sbc.git;a=summary) and its patent
has expired June 2, 2010. (source:
http://en.wikipedia.org/wiki/SBC_(codec)), I wonder if it wouldn't be
a good idea to move the plugin to gstreamer tree?
The plugin has the following elements:
bluetooth: sbcenc: Bluetooth SBC encoder
bluetooth: sbcdec: Bluetooth SBC decoder
bluetooth: sbcparse: Bluetooth SBC parser
bluetooth: avdtpsink: Bluetooth AVDTP sink
bluetooth: a2dpsink: Bluetooth A2DP sink
bluetooth: rtpsbcpay: RTP packet payloader
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v4 01/10] Battery: Add Battery Service Gatt Client
From: Chen Ganir @ 2012-08-16 12:55 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20120816124410.GB24627@x220>
Johan,
On 08/16/2012 03:44 PM, Johan Hedberg wrote:
> Hi Chen,
>
> On Thu, Aug 16, 2012, Chen Ganir wrote:
>>> I don't think it's ok to pollute the Device interface or src/device.c
>>> with profile-specific details. That should happen in profile-specific
>>> plugins and interfaces. Since we're switching over to object manager
>>> maybe an interface/property like this isn't needed at all? (even if it
>>> would be needed the type should be array{object} and not array{string}
>>
>> You are correct, the array should be object instead of string.
>> However, i fail to understand why the object manager prevents this
>> from getting accepted - do you have a time estimation when the
>> object manager should be active or available ?
>
> By the time of our next release (as per the content under the BlueZ 5
> section in our TODO file).
Is there anywhere some documentation or instructions how to adapt the
API for the new object manager ? Is it backward compatible to what we
have today ? Do we really hold back DBUS additions until we change the
DBUS API ?
>
>> I prefer this way of putting the batteries below the device, since it
>> is obvious which battery belongs to each device.
>
> I fully agree with this. It's not what I had an issue with. However, if
> we really want to make this clear you could additionally have a "Device"
> property for each battery object pointing back to the parent object.
I can do that, if it helps. Although it is not necessary, since the
object path for a battery already contains the device objec path in it :
[variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
Adding a device object path as a property will be redundant.
>
>> The other option i can think of is to have another interface
>> registered on the device object path:
>>
>> Service org.bluez
>> Interface org.bluez.Batteries
>> Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX
>>
>> Methods dict GetProperties()
>>
>> Returns all properties for the interface. See the
>> Properties section for the available properties.
>>
>> Signals ProperyChanged(string name, variant value)
>>
>> This signal indicates a changed value of the given
>> property.
>>
>> Properties array{object} Batteries [readonly]
>>
>> List of device battery object paths that represents the available
>> batteries on the remote devices.
>>
>>
>> Service org.bluez
>> Interface org.bluez.Battery
>> Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
>>
>>
>> Methods dict GetProperties()
>>
>> Returns all properties for the interface. See the
>> Properties section for the available properties.
>>
>> Signals PropertyChanged(string name, variant value)
>>
>> This signal indicates a changed value of the given
>> property.
>>
>> Properties byte Level [readonly]
>>
>> Battery level (0-100).
>>
>> Any other suggestion ?
>
> That would work, although both of these interfaces are rather
> light-weight in that they only contain a single property which begs the
> question whether this is a bit over-kill.
I know. I believe so as well, but if you want to separate the
interfaces, it is a must.
>
> Another option is to do away with the per-battery object somehow and
> expose all batteries through a single interface. I'm not so sure that's
> a good idea though since it could prevent future extensibility of the
> API and doesn't reuse the common tools we have for object-like
> abstractions (which a battery certainly is).
If we do what you suggest, a battery name (namespace+descriptor) will be
the property name, and the value should be the battery level. i'm not
too comfortable with it, and it is different than what we used to do up
until now.
So where do we go from here ?
>
> Johan
>
--
BR,
Chen Ganir
Texas Instruments
^ permalink raw reply
* Re: [PATCH BlueZ v0 00/10] GAP Plugin
From: Claudio Takahasi @ 2012-08-16 12:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345040407-17767-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Johan:
On Wed, Aug 15, 2012 at 11:19 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> This patch series adds a new GATT based plugin for GAP service. The
> objective is cleanup: moving some GATT related operations from the
> device(core) to a GATT based plugin.
Ignore this patch series. As discussed in the IRC, a new GATT plugin
will be created to handle GAP and GATT services characteristics.
The term "GAP" for a GAP characteristics plug-in is not suitable since
it may create misinterpretation with GAP BR/EDR.
BR,
Claudio
^ permalink raw reply
* [PATCH BlueZ v1] gdbus: Fix compilation error if macro "error" is defined
From: Jaganath Kanakkassery @ 2012-08-16 12:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jaganath Kanakkassery
The variable "signature" used in error is not defined and "args" is now
a struct instead of a string.
---
v1 -> Made a note of the removal of variable "args" in the commit message
gdbus/object.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gdbus/object.c b/gdbus/object.c
index 900e7ab..9689006 100644
--- a/gdbus/object.c
+++ b/gdbus/object.c
@@ -645,8 +645,8 @@ static dbus_bool_t emit_signal_valist(DBusConnection *conn,
goto fail;
if (g_dbus_args_have_signature(args, signal) == FALSE) {
- error("%s.%s: expected signature'%s' but got '%s'",
- interface, name, args, signature);
+ error("%s.%s: got unexpected signature '%s'", interface, name,
+ dbus_message_get_signature(signal));
ret = FALSE;
goto fail;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH BlueZ v0] gdbus: Fix compilation error if macro "error" is defined
From: Jaganath Kanakkassery @ 2012-08-16 12:48 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20120816123023.GA24627@x220>
Hi Johan,
--------------------------------------------------
From: "Johan Hedberg" <johan.hedberg@gmail.com>
Sent: Thursday, August 16, 2012 6:00 PM
To: "Jaganath Kanakkassery" <jaganath.k@samsung.com>
Cc: <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ v0] gdbus: Fix compilation error if macro "error"
is defined
> Hi Jaganath,
>
> On Thu, Aug 16, 2012, Jaganath Kanakkassery wrote:
>> >On Wed, Aug 01, 2012, Jaganath Kanakkassery wrote:
>> >>The variable "signature" used in error is not defined.
>> >>---
>> >>v0 -> Made error message as per Lucas's suggestion
>> >>
>> >> gdbus/object.c | 4 ++--
>> >> 1 files changed, 2 insertions(+), 2 deletions(-)
>> >>
>> >>diff --git a/gdbus/object.c b/gdbus/object.c
>> >>index 900e7ab..9689006 100644
>> >>--- a/gdbus/object.c
>> >>+++ b/gdbus/object.c
>> >>@@ -645,8 +645,8 @@ static dbus_bool_t
>> >>emit_signal_valist(DBusConnection *conn,
>> >> goto fail;
>> >>
>> >> if (g_dbus_args_have_signature(args, signal) == FALSE) {
>> >>- error("%s.%s: expected signature'%s' but got '%s'",
>> >>- interface, name, args, signature);
>> >>+ error("%s.%s: got unexpected signature '%s'", interface, name,
>> >>+ dbus_message_get_signature(signal));
>> >> ret = FALSE;
>> >> goto fail;
>> >> }
>> >
>> >What's the reason for dropping printing of the value of "args"? I'd
>> >think that's quite useful in figuring out what went wrong. Even if there
>> >is a reason to drop it it has nothing to do with fixing the compilation
>> >error due to undefined "signature" and should therefore be in its own
>> >patch.
>> >
>>
>> "args" is a structure now and that's the reason it is removed and I think
>> the complete signature of args cannot be available at the point
>> where it is printed.
>> How about changing the commit message to "Correct error message"?
>
> No, keep the summary line as is, but please add a note about this args
> variable to the rest of the message, i.e. something like "The variable
> "signature" is not defined and "args" is now a struct instead of a
> string".
Ok, I will raise v1,
Thanks,
Jaganath
^ permalink raw reply
* Re: [PATCH v4 01/10] Battery: Add Battery Service Gatt Client
From: Johan Hedberg @ 2012-08-16 12:44 UTC (permalink / raw)
To: Chen Ganir; +Cc: linux-bluetooth
In-Reply-To: <502CE43C.7040804@ti.com>
Hi Chen,
On Thu, Aug 16, 2012, Chen Ganir wrote:
> >I don't think it's ok to pollute the Device interface or src/device.c
> >with profile-specific details. That should happen in profile-specific
> >plugins and interfaces. Since we're switching over to object manager
> >maybe an interface/property like this isn't needed at all? (even if it
> >would be needed the type should be array{object} and not array{string}
>
> You are correct, the array should be object instead of string.
> However, i fail to understand why the object manager prevents this
> from getting accepted - do you have a time estimation when the
> object manager should be active or available ?
By the time of our next release (as per the content under the BlueZ 5
section in our TODO file).
> I prefer this way of putting the batteries below the device, since it
> is obvious which battery belongs to each device.
I fully agree with this. It's not what I had an issue with. However, if
we really want to make this clear you could additionally have a "Device"
property for each battery object pointing back to the parent object.
> The other option i can think of is to have another interface
> registered on the device object path:
>
> Service org.bluez
> Interface org.bluez.Batteries
> Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX
>
> Methods dict GetProperties()
>
> Returns all properties for the interface. See the
> Properties section for the available properties.
>
> Signals ProperyChanged(string name, variant value)
>
> This signal indicates a changed value of the given
> property.
>
> Properties array{object} Batteries [readonly]
>
> List of device battery object paths that represents the available
> batteries on the remote devices.
>
>
> Service org.bluez
> Interface org.bluez.Battery
> Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
>
>
> Methods dict GetProperties()
>
> Returns all properties for the interface. See the
> Properties section for the available properties.
>
> Signals PropertyChanged(string name, variant value)
>
> This signal indicates a changed value of the given
> property.
>
> Properties byte Level [readonly]
>
> Battery level (0-100).
>
> Any other suggestion ?
That would work, although both of these interfaces are rather
light-weight in that they only contain a single property which begs the
question whether this is a bit over-kill.
Another option is to do away with the per-battery object somehow and
expose all batteries through a single interface. I'm not so sure that's
a good idea though since it could prevent future extensibility of the
API and doesn't reuse the common tools we have for object-like
abstractions (which a battery certainly is).
Johan
^ permalink raw reply
* Re: [PATCH BlueZ v0] gdbus: Fix compilation error if macro "error" is defined
From: Johan Hedberg @ 2012-08-16 12:30 UTC (permalink / raw)
To: Jaganath Kanakkassery; +Cc: linux-bluetooth
In-Reply-To: <69D93B07FE0348AC8E5E38C3EF8D6DB7@sisodomain.com>
Hi Jaganath,
On Thu, Aug 16, 2012, Jaganath Kanakkassery wrote:
> >On Wed, Aug 01, 2012, Jaganath Kanakkassery wrote:
> >>The variable "signature" used in error is not defined.
> >>---
> >>v0 -> Made error message as per Lucas's suggestion
> >>
> >> gdbus/object.c | 4 ++--
> >> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/gdbus/object.c b/gdbus/object.c
> >>index 900e7ab..9689006 100644
> >>--- a/gdbus/object.c
> >>+++ b/gdbus/object.c
> >>@@ -645,8 +645,8 @@ static dbus_bool_t
> >>emit_signal_valist(DBusConnection *conn,
> >> goto fail;
> >>
> >> if (g_dbus_args_have_signature(args, signal) == FALSE) {
> >>- error("%s.%s: expected signature'%s' but got '%s'",
> >>- interface, name, args, signature);
> >>+ error("%s.%s: got unexpected signature '%s'", interface, name,
> >>+ dbus_message_get_signature(signal));
> >> ret = FALSE;
> >> goto fail;
> >> }
> >
> >What's the reason for dropping printing of the value of "args"? I'd
> >think that's quite useful in figuring out what went wrong. Even if there
> >is a reason to drop it it has nothing to do with fixing the compilation
> >error due to undefined "signature" and should therefore be in its own
> >patch.
> >
>
> "args" is a structure now and that's the reason it is removed and I think
> the complete signature of args cannot be available at the point
> where it is printed.
> How about changing the commit message to "Correct error message"?
No, keep the summary line as is, but please add a note about this args
variable to the rest of the message, i.e. something like "The variable
"signature" is not defined and "args" is now a struct instead of a
string".
Johan
^ permalink raw reply
* Re: [RFC BlueZ v2] mgmt-api: Add reason to device disconnect event
From: Johan Hedberg @ 2012-08-16 12:25 UTC (permalink / raw)
To: Mikel Astiz; +Cc: linux-bluetooth, Mikel Astiz
In-Reply-To: <1344498980-2829-1-git-send-email-mikel.astiz.oss@gmail.com>
Hi Mikel,
On Thu, Aug 09, 2012, Mikel Astiz wrote:
> From: Mikel Astiz <mikel.astiz@bmw-carit.de>
>
> Extend the management API with the disconnect reason, as now reported
> by the Kernel in MGMT_EV_DEVICE_DISCONNECTED.
> ---
> Updated userland patch to test the recently submitted Kernel patches regarding ACL disconnect reason.
>
> doc/mgmt-api.txt | 16 ++++++++++++++++
> lib/mgmt.h | 6 ++++++
> monitor/control.c | 19 +++++++++++++++----
> src/mgmt.c | 13 ++++++++-----
> 4 files changed, 45 insertions(+), 9 deletions(-)
Seems like you're missing an update to tools/btmgmt.c?
> --- a/monitor/control.c
> +++ b/monitor/control.c
> @@ -226,18 +226,29 @@ static void mgmt_device_disconnected(uint16_t len, const void *buf)
> {
> const struct mgmt_ev_device_disconnected *ev = buf;
> char str[18];
> + uint8_t reason;
> + uint16_t l;
I suppose size_t would be more appropriate instead of uint16_t as that's
the return type of sizeof(). The variable name is also a bit
uninformative and I'd have used something like consumed_len or
parsed_len, but if this the convention in rest of the btmon code then I
wont object to it.
> --- a/src/mgmt.c
> +++ b/src/mgmt.c
> @@ -510,18 +510,21 @@ static void mgmt_device_connected(int sk, uint16_t index, void *buf, size_t len)
> static void mgmt_device_disconnected(int sk, uint16_t index, void *buf,
> size_t len)
> {
> - struct mgmt_addr_info *ev = buf;
> + struct mgmt_ev_device_disconnected *ev = buf;
> struct controller_info *info;
> char addr[18];
>
> - if (len < sizeof(*ev)) {
> + if (len < sizeof(struct mgmt_addr_info)) {
> error("Too small device_disconnected event");
> return;
> }
>
> - ba2str(&ev->bdaddr, addr);
> + if (len < sizeof(*ev))
> + memset((char *) buf + len, 0, sizeof(*ev) - len);
I don't like how this assumes that there is usable space after the end
of the buffer given to this function. Could you instead use a temporary
"uint8_t reason" variable like you do for btmon?
Johan
^ permalink raw reply
* Re: [PATCH v4 01/10] Battery: Add Battery Service Gatt Client
From: Chen Ganir @ 2012-08-16 12:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20120816113941.GA20887@x220>
On 08/16/2012 02:39 PM, Johan Hedberg wrote:
> Hi Chen,
>
> On Thu, Aug 16, 2012, chen.ganir@ti.com wrote:
>> --- a/doc/device-api.txt
>> +++ b/doc/device-api.txt
>> @@ -179,3 +179,8 @@ Properties string Address [readonly]
>> Note that this property can exhibit false-positives
>> in the case of Bluetooth 2.1 (or newer) devices that
>> have disabled Extended Inquiry Response support.
>> +
>> + array{string} Batteries [readonly]
>> +
>> + List of device battery object paths that represents the available
>> + batteries on the remote device.
>
> I don't think it's ok to pollute the Device interface or src/device.c
> with profile-specific details. That should happen in profile-specific
> plugins and interfaces. Since we're switching over to object manager
> maybe an interface/property like this isn't needed at all? (even if it
> would be needed the type should be array{object} and not array{string}
You are correct, the array should be object instead of string. However,
i fail to understand why the object manager prevents this from getting
accepted - do you have a time estimation when the object manager should
be active or available ? I do not think this patch set should be
deferred until we have changed the dbus API.
I prefer this way of putting the batteries below the device, since it is
obvious which battery belongs to each device. The other option i can
think of is to have another interface registered on the device object path:
Service org.bluez
Interface org.bluez.Batteries
Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX
Methods dict GetProperties()
Returns all properties for the interface. See the
Properties section for the available properties.
Signals ProperyChanged(string name, variant value)
This signal indicates a changed value of the given
property.
Properties array{object} Batteries [readonly]
List of device battery object paths that represents the available
batteries on the remote devices.
Service org.bluez
Interface org.bluez.Battery
Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
Methods dict GetProperties()
Returns all properties for the interface. See the
Properties section for the available properties.
Signals PropertyChanged(string name, variant value)
This signal indicates a changed value of the given
property.
Properties byte Level [readonly]
Battery level (0-100).
Any other suggestion ?
>
> Johan
>
--
BR,
Chen Ganir
Texas Instruments
^ permalink raw reply
* Re: [PATCH BlueZ] lib: Add new company identifiers
From: Johan Hedberg @ 2012-08-16 12:05 UTC (permalink / raw)
To: Jefferson Delfes; +Cc: linux-bluetooth
In-Reply-To: <1343673680-30775-1-git-send-email-jefferson.delfes@openbossa.org>
Hi Jefferson,
On Mon, Jul 30, 2012, Jefferson Delfes wrote:
> ---
> lib/bluetooth.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ v0] gdbus: Fix compilation error if macro "error" is defined
From: Jaganath Kanakkassery @ 2012-08-16 12:01 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20120816074909.GA29336@x220>
Hi Johan,
--------------------------------------------------
From: "Johan Hedberg" <johan.hedberg@gmail.com>
Sent: Thursday, August 16, 2012 1:19 PM
To: "Jaganath Kanakkassery" <jaganath.k@samsung.com>
Cc: <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ v0] gdbus: Fix compilation error if macro "error"
is defined
> Hi Jaganath,
>
> On Wed, Aug 01, 2012, Jaganath Kanakkassery wrote:
>> The variable "signature" used in error is not defined.
>> ---
>> v0 -> Made error message as per Lucas's suggestion
>>
>> gdbus/object.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdbus/object.c b/gdbus/object.c
>> index 900e7ab..9689006 100644
>> --- a/gdbus/object.c
>> +++ b/gdbus/object.c
>> @@ -645,8 +645,8 @@ static dbus_bool_t emit_signal_valist(DBusConnection
>> *conn,
>> goto fail;
>>
>> if (g_dbus_args_have_signature(args, signal) == FALSE) {
>> - error("%s.%s: expected signature'%s' but got '%s'",
>> - interface, name, args, signature);
>> + error("%s.%s: got unexpected signature '%s'", interface, name,
>> + dbus_message_get_signature(signal));
>> ret = FALSE;
>> goto fail;
>> }
>
> What's the reason for dropping printing of the value of "args"? I'd
> think that's quite useful in figuring out what went wrong. Even if there
> is a reason to drop it it has nothing to do with fixing the compilation
> error due to undefined "signature" and should therefore be in its own
> patch.
>
"args" is a structure now and that's the reason it is removed and I think
the complete signature of args cannot be available at the point where it is
printed.
How about changing the commit message to "Correct error message"?
Thanks,
Jaganath
^ permalink raw reply
* Re: [PATCH v4 01/10] Battery: Add Battery Service Gatt Client
From: Johan Hedberg @ 2012-08-16 11:39 UTC (permalink / raw)
To: chen.ganir; +Cc: linux-bluetooth
In-Reply-To: <1345109702-5698-2-git-send-email-chen.ganir@ti.com>
Hi Chen,
On Thu, Aug 16, 2012, chen.ganir@ti.com wrote:
> --- a/doc/device-api.txt
> +++ b/doc/device-api.txt
> @@ -179,3 +179,8 @@ Properties string Address [readonly]
> Note that this property can exhibit false-positives
> in the case of Bluetooth 2.1 (or newer) devices that
> have disabled Extended Inquiry Response support.
> +
> + array{string} Batteries [readonly]
> +
> + List of device battery object paths that represents the available
> + batteries on the remote device.
I don't think it's ok to pollute the Device interface or src/device.c
with profile-specific details. That should happen in profile-specific
plugins and interfaces. Since we're switching over to object manager
maybe an interface/property like this isn't needed at all? (even if it
would be needed the type should be array{object} and not array{string}
Johan
^ permalink raw reply
* Re: Bluez 4.101
From: Anderson Lizardo @ 2012-08-16 10:57 UTC (permalink / raw)
To: John Tobias; +Cc: Chan-yeol Park, linux-bluetooth
In-Reply-To: <CACUGKYOUh6G9zkifB98akXd_R8Axv6eh03-OCYnJyLNkkBTq3w@mail.gmail.com>
Hi John,
On Wed, Aug 15, 2012 at 10:54 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Let me take it back. I used the kernel from ubuntu 12.04.
You need at least 3.4.0 to use latest BlueZ (although the latest
kernel version is always recommended for development). Ubuntu 12.04
has 3.2.0.
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ 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